On Fri, Jul 15, 2016 at 1:53 PM, Lance Richardson <lrich...@redhat.com> wrote:
> I've been doing some investigation into the "Limiting the impact of > a compromised chassis" issue described in ovn/TODO. These are some initial > thoughts, posting here for feedback and any other ideas folks might have > about how we should go about solving this part of the issue. > > The fact that we're heading towards using etcd for OVN might make some > of this moot, on the other hand it might be some time before that happens > and this security issue will need to be addressed in order for OVN to be > viable in some use cases. > I've been thinking about whether it still makes sense to work on this before migrating to etcd. Since the etcd timeline is unclear, and this issue is a blocker for some people in the meantime, I think it's worth proceeding, at least with scoping the work. If we can come up with a detailed proposal, we can hopefully get a better idea of how much work it would be and if it's worth the short term effort. > One problem that needs to be solved for any potential solution to the > compromised chassis issue is how to determine the identity of clients > connecting to the OVN southbound DB server. For example, it would be > desirable for ovn-northd and ovn-sbctl to have one set of access privileges > for reading and updating the SB database while ovn-controller and > ovn-controller-vtep have a different and more limited set of access > privileges. In order to implement this it would be necessary to know for > each transaction the type of client attempting it. For more fine-grained > access control, it will also be necessary to determine the actual identity > (e.g. chassis name or UUID) of each connected client. > > Since ovsdb-server already has support for SSL client authentication, one > semi-obvious approach might be to: > - Configure the SB ovsdb-server to only accept unix and SSL connections > (ovn-northd and ovn-sbctl would likely use unix:file connections, > where > access can be controlled via file system permissions, whereas > ovn-controller > instances would use SSL). > - Generate signed client certificates for each chassis/gateway, > encoding the > chassis/gateway name in the certificate's "organizational unit" field. > - In cases where ovn-northd or ovn-sbctl might have to connect to the SB > database server over a network, client certificates could be generated > with e.g. the OU field set to "ovn-northd" or "ovn-sbctl" as > appropriate. > - For each new SSL connection, ovsdb-server would record the client type > and name contained in the client-provided certificate. > - The recorded client type and name could then be used in a (to be > defined > separately) ACL implementation. > > Some questions: > > - Will this work, and are there any obvious holes? > - Might PKI management be too burdensome in large deployments? > - Is there a better way? > If we need identify for each chassis, this does seem like a good approach. I was imagining we'd do it with SSL, but hadn't thought through details yet. The other option is if we can change ovn-controller to where it is only a read-only client of the southbound database. In that case, perhaps ovsdb-server wouldn't need to know identity, and instead could have a port open that only accepts connections with read-only access to the database. -- Russell Bryant
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
