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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
