> From: "Ben Pfaff" <b...@ovn.org> > To: "Russell Bryant" <russ...@ovn.org> > Cc: "Lance Richardson" <lrich...@redhat.com>, "ovs dev" > <dev@openvswitch.org>, "Russell Bryant" <rbry...@redhat.com> > Sent: Monday, August 22, 2016 1:22:43 PM > Subject: Re: [ovs-dev] [RFC] ovn: minimize the impact of a compromised chassis > > 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. >
Based on my own narrow view of the world, I think option #1 would need: - The ability for ovsdb-server to associate a role/identity with each client connection. For simplicity this could be a binary "privileged" vs "non-privileged" association, perhaps using per-role SSL certificates for TLS connections and treating unix socket connections as "privileged". - A mechanism for mapping a role/identity to access rights on a per-table and per-column basis. - A mechanism for enforcing access rights on a per-table or per-column basis, in some cases also considering the identity of the client that created the row. This infrastructure would be applied to OVN to implement the following: - These tables would be read-only for non-privileged clients: SB_Global, Logical_Flow, Multicast_Group, Datapath_Binding, Address_Set, DHCP_Options, and DHCPv6_Options. - The Chassis and Encap tables would allow insertions by non-privileged clients and updates to existing rows only for the clients that inserted them. - The Port_Binding table would be writable only by privileged clients (ovn-northd) except for the "Chassis" column which should be writable by any non-privileged client (note that this doesn't do a lot to minimize harm from a compromised chassis). - The MAC_Binding table should be writable by any non-privileged client (which also doesn't do much to minimize harm from a compromised chassis). > > 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. > Here's a slightly more detailed breakdown of the work needed for option #2: ovsdb-server: Add support for "read-only" connections. Perhaps something like "--remote ptcp:read-only:<port>[:<ip>]" and variations on that theme for other connection types. ovn-controller: Implement new approach for Chassis and Encap tables: - Remove code from ovn-controller for creating rows in these tables. - Document how administrators create rows using ovn-sbctl in ovn-controller man page. - Update all tests to manually create Chassis/Encap rows. ovn-controller: Implement new approach for chassis column in Port_Binding table: - Remove the code to update the chassis column from ovn-controller. - Add new key to options column of Logical_Switch_Port in OVN_Northbound database to specify chassis binding. - Change ovn-northd to update Port_Binding table in southbound db based on chassis option from Logical_Switch_port in northbound db. - Write upgrade helper script that sets chassis option for existing Logical_Switch_Ports based on current values in Port_Binding table of southbound db - Document OVN upgrade procedure, including the use of the upgrade helper script. ovn-controller: Rework MAC_Binding table - Propose details of chassis-local mac bindings storage, the two main options are: + In ovn-controller memory (simple, but cache reset on ovn-controller restart). + In Open_vSwitch database (more work, as we need cache invalidation logic added). - Change ovn-controller to use local store for learned mac bindings. - Remove code for updating MAC_Binding table from ovn-controller. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev