Commit 0565f862 authored by Helga Velroyen's avatar Helga Velroyen

Update design doc wrt to improved SSL design

This patch updates the design document of Ganeti's node
security to make it consistent with the implementation
and to extend it with a couple of suggestions to improve
the SSL security even more.
Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
parent e593c9c8
......@@ -105,8 +105,8 @@ distribution to master candidates only.
(Re-)Adding nodes to a cluster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
According to ``design-node-add.rst``, Ganeti transfers the ssh keys to every
node that gets added to the cluster.
According to :doc:`design-node-add`, Ganeti transfers the ssh keys to
every node that gets added to the cluster.
We propose to change this procedure to treat master candidates and normal
nodes differently. For master candidates, the procedure would stay as is.
......@@ -192,7 +192,10 @@ in the design.
- Instead of using the same certificate for all nodes as both, server
and client certificate, we generate a common server certificate (and
the corresponding private key) for all nodes and a different client
certificate (and the corresponding private key) for each node.
certificate (and the corresponding private key) for each node. All
those certificates will be self-signed for now. The client
certificates will use the node UUID as serial number to ensure
uniqueness within the cluster.
- In addition, we store a mapping of
(node UUID, client certificate digest) in the cluster's configuration
and ssconf for hosts that are master or master candidate.
......@@ -248,6 +251,9 @@ Drawbacks of this design:
design (limiting ssh keys to master candidates), but it will be
eliminated with the second part of the design (separate ssh keys for
each master candidate).
- Even though this proposal is an improvement towards the previous
situation in Ganeti, it still does not use the full power of SSL. For
further improvements, see Section "Related and future work".
Alternative proposals:
......@@ -379,7 +385,7 @@ in this design so far. Also, other daemons than the ones mentioned so far
perform intra-cluster communication. Neither the keys nor the daemons will
be affected by this design for several reasons:
- The hmac key used by ConfD (see ``design-2.1.rst``): the hmac key is still
- The hmac key used by ConfD (see :doc:`design-2.1`): the hmac key is still
distributed to all nodes, because it was designed to be used for
communicating with ConfD, which should be possible from all nodes.
For example, the monitoring daemon which runs on all nodes uses it to
......@@ -392,7 +398,7 @@ be affected by this design for several reasons:
RPC requests is maintained with this design.
- The rapi SSL key certificate and rapi user/password file 'rapi_users' is
already only copied to the master candidates (see ``design-2.1.rst``,
already only copied to the master candidates (see :doc:`design-2.1`,
Section ``Redistribute Config``).
- The spice certificates are still distributed to all nodes, since it should
......@@ -407,9 +413,51 @@ be affected by this design for several reasons:
Related and Future Work
~~~~~~~~~~~~~~~~~~~~~~~
Ganeti RPC calls are currently done without server verification.
Establishing server verification might be a desirable feature, but is
not part of this design.
There a couple of suggestions on how to improve the SSL setup even more.
As a trade-off wrt to complexity and implementation effort, we did not
implement them yet (as of version 2.11) but describe them here for
future reference.
- All SSL certificates that Ganeti uses so far are self-signed. It would
increase the security if they were signed by a common CA. There is
already a design doc for a Ganeti CA which was suggested in a
different context (related to import/export). This would also be a
benefit for the RPC calls. See design doc :doc:`design-impexp2` for
more information. Implementing a CA is rather complex, because it
would mean also to support renewing the CA certificate and providing
and supporting infrastructure to revoke compromised certificates.
- An extension of the previous suggestion would be to even enable the
system administrator to use an external CA. Especially in bigger
setups, where already an SSL infrastructure exists, it would be useful
if Ganeti can simply be integrated with it, rather than forcing the
user to use the Ganeti CA.
- A lighter version of using a CA would be to use the server certificate
to sign the client certificate instead of using self-signed
certificates for both. The probleme here is that this would make
renewing the server certificate rather complicated, because all client
certificates would need to be resigned and redistributed as well,
which leads to interesting chicken-and-egg problems when this is done
via RPC calls.
- Ganeti RPC calls are currently done without checking if the hostname
of the node complies with the common name of the certificate. This
might be a desirable feature, but would increase the effort when a
node is renamed.
- The typical use case for SSL is to have one certificate per node
rather than one shared certificate (Ganeti's noded server certificate)
and a client certificate. One could change the design in a way that
only one certificate per node is used, but this would require a common
CA so that the validity of the certificate can be established by every
node in the cluster.
- With the proposed design, the serial numbers of the client
certificates are set to the node UUIDs. This is technically also not
complying to how SSL is supposed to be used, as the serial numbers
should reflect the enumeration of certificates created by the CA. Once
a CA is implemented, it might be reasonable to change this
accordingly. The implementation of the proposed design also has the
drawback of the serial number not changing even if the certificate is
replaced by a new one (for example when calling ``gnt-cluster renew-
crypt``), which also does not comply to way SSL was designed to be
used.
.. vim: set textwidth=72 :
.. Local Variables:
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment