[ovs-dev] [RFC] ovn: minimize the impact of a compromised chassis

Ben Pfaff blp at ovn.org
Mon Aug 22 16:30:16 UTC 2016


On Tue, Aug 16, 2016 at 09:30:21AM -0400, Lance Richardson wrote:
> As described in ovn/TODO, these are the two main approaches that could be
> used to minimize the impact of a compromised chassis on the rest of an
> OVN OVN network:
> 
>   1) Implement a role- or identity-based access control mechanism for
>      ovsdb-server and use it to limit ovn-controller write access to
>      tables in the southbound database.
> 
> or
> 
>   2) Disallow all write access to the southbound database by ovn-controller 
>      (as an optional mode or unconditionally) and provide alternative
>      mechanisms for updating the southbound database for entries that are
>      currently updated by ovn-controller.
>      
> It is believed that option (1) would require somewhat more effort than (2),
> and, because it would involve significant modifications to ovsdb-server,
> would also be more likely to add risk and burden to non-OVN users.
> Additionally, option (2) will likely place fewer requirements on alternative
> databases (such as etcd), so the following implementation discussion only
> considers option (2).

I've always pushed back against adding granular access control
mechanisms to OVSDB because I didn't believe it was likely that anything
that was simple enough to be in the "spirit of OVSDB" (heh) was also
going to be sufficient to fit a real use case.  However, if we do now
have specific requirements for OVN, then I'd invite descriptions of what
access control mechanism would be sufficient.  If it's simple and
general enough, then implementing it in OVSDB might totally make sense.

I don't think that the "risk and burden" of a simple and general
mechanism is a real issue.



More information about the dev mailing list