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.
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?
Thanks,
Lance
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
