On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu <dm...@cornell.edu> wrote:
> I'd argue for the approach of keeping the OVSDB protocol in place, because > the SB schema is already there, well understood, and making the central DB > a fault tolerant cluster would have little or no impact on the > ovs-controller implementation. It would also allow the current single OVSDB > to continue to function while the cluster is developed. > > That said, if the current OVSDB doesn't have an ACL model, I have some > security and robustness concerns, once it's run at scale. Has it been > considered to add an ACL model to OVSDB? > I've put some thought into the security concerns of the southbound database. I wrote a bit about this in the ovn/TODO file. See "limiting the impact of a compromised chassis". https://github.com/openvswitch/ovs/blob/master/ovn/TODO#L128 Since writing that, I've come to think that as a first step, making ovn-controller (at least optionally) only have read-only access to the southbound database would be a good step. This would require: - Instead of having ovn-controller create the Chassis and Encap rows for itself, make that an administrative task when bring a new chassis online. This can be done with the ovn-sbctl utility. It's data that is set once and very rarely changed. - Move the job of assigning port bindings. Right now ovn-controller sees ports appear locally and automatically matches them up with OVN logical ports and updates the port bindings. This is quite convenient, but we could optionally force an external entity to define the port bindings instead. In the case of OpenStack, the Neutron plugin could do this. In fact, Neutron already expects to be in charge of port-host bindings, and we just ignore that for OVN right now. If we take that route, this doesn't seem too hard to do. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
