On Tue, Aug 16, 2016 at 9:30 AM, Lance Richardson <lrich...@redhat.com> wrote:
> Soliciting feedback/discussion to sanity-check proposed solution (described > below) before implementation. > > Thanks, > > Lance > > --- > > Limiting the impact of a compromised chassis. > > Problem Description: > ------------------- > Each ovn-controller instance currently has full write access to the OVN > southbound database. This means that a single compromised chassis can > potentially disrupt every chassi in an OVN network. This has been raised > as a concern that needs to be addressed before OVN can be deployed in at > least one known target environment. > > Possible Solutions: > ------------------- > 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). > > Implementation (Option 2) > ------------------------- > > These SB db tables should never be modified by ovn-controller, and can be > made read-only for ovn-controller without impact: > SB_Global > Logical_Flow > Multicast_Group > Datapath_Binding > Address_Set > DHCP_Options > DHCPv6_Options > > The following tables, however, do currently need to be written by > ovn-controller. > Making them read-only for ovn-controller will require changes, as noted: > > Chassis > Encap > Port_Binding > A mechanism will be needed to allow the CMS to provision these tables. > For example, Chassis and Encap could be set via ovn-sbctl as an > administrative task when provisioning a new chassis. For Port_Binding, > the CMS could update the table directly (although the CMS doesn't > write to the SB db today), or perhaps a new key could be added to the > Logical_Switch_Port's Options column in the NB db to allow the chassis > binding for the port to be specified and propagated to the SB db by > northd. > > MAC_Binding > Provisioning the the Port_Binding table from the CMS will take care of > static IP-MAC bindings, however some means will still be needed for > handling dynamic bindings. One possibility would be to remove the > tracking of dynamic bindings from the southbound db and make this > function the responsibility of each individual chassis. > Thanks for starting this discussion. I do think making ovn-controller a read-only client of the database seems like the simplest path forward. We should pursue that until we hit a strong reason not to. One of the biggest questions remaining for me is how we deal with backwards compatibility. Whatever we do here will have to account for what happens for environments running OVN from OVS 2.6 when they upgrade. Perhaps the most straight forward way to do that is to make this new more secure mode optional and off by default. The downside is that it makes the system more complex, since it will have different modes it can work. An alternative would be to provide some tooling to assist with the upgrade: - Document the new requirements for creating Chassis and Encap rows manually - Provide an upgrade tool (via ovn-nbctl/ovn-sbctl/something-else) that will add the "chassis" option to logical ports set based on where ports are currently bound in the southbound database. - Provide an upgrade tool that converts the MAC_Binding table to whatever the new chassis local storage for that information would be. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
