On Mon, Aug 22, 2016 at 01:14:03PM -0400, Russell Bryant wrote: > On Mon, Aug 22, 2016 at 12:30 PM, Ben Pfaff <b...@ovn.org> wrote: > > > 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. > > > I think that push back makes sense. > > The proposal here was to take route #2. The only OVSDB feature required in > that case is to accept read-only connections, which could be on a > per-socket basis. This seems much simpler all around, as long as we can > all get on board with ovn-controller as a read-only client.
I'm not actually saying we should choose #1. I'm saying a couple of things. First, changing OVSDB is not a huge deal; we do it when it makes sense. Second, that it is possible that our specific application here is a better place to start for OVSDB access control than a blanket "we need access control for OVSDB" that I've heard a couple of times. > Are you interested in looking closer at what #1 would look like, with > details of what the access control policy would look like? It'll probably be obvious, or close to obvious, what would be needed for #1 once we talk through what #2 needs. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
