From 4fbe765c8abb924646de8e0bc9b979746b22cd15 Mon Sep 17 00:00:00 2001
From: Michael Hanselmann <hansmi@google.com>
Date: Mon, 6 Oct 2008 11:01:49 +0000
Subject: [PATCH] Update document describing cluster security
It may need further updates, but here's a start.
Reviewed-by: ultrotter
---
SECURITY | 62 ++++++++++++++++++++++++++++++++++----------------------
1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/SECURITY b/SECURITY
index 448dbf558..6c0309e23 100644
--- a/SECURITY
+++ b/SECURITY
@@ -12,21 +12,22 @@ you need to be root to run the cluster commands.
Host issues
-----------
-For a host on which the Ganeti software has been installed but which has
-not been joined in a cluster, there are no changes to the system.
+For a host on which the Ganeti software has been installed, but not joined to a
+cluster, there are no changes to the system.
For a host that has been joined to the cluster, there are very important
changes:
- - the host will have its ssh host key replaced with the one of the
+ - The host will have its SSH host key replaced with the one of the
cluster (which is the one the initial node had at the cluster
creation)
- - root will have added to its authorized_keys file a public key which
- grants access to all other nodes in the cluster, and furthermore it
- will also get the private part of this key, which will allow it to
- login to the other nodes in the cluster (its previous private key
- will be backed up)
- - the Ganeti node daemon will accept RPC requests from any host which
- has the cluster shared secret, and the operations it will do as a
+ - A new public key will be added to root's authorized_keys file, granting
+ root access to all nodes of the cluster. The private part of the key
+ is also distributed to all nodes. Old files are renamed.
+ - Communication between nodes is encrypted using SSL/TLS. A common
+ key and certificate combo is shared between all nodes of the cluster.
+ At this time, no CA is used.
+ - The Ganeti node daemon will accept RPC requests from any host within the
+ cluster with the correct certificate, and the operations it will do as a
result of these requests are:
- running commands under the /etc/ganeti/hooks directory
- creating DRBD disks between it and the IP it has been told
@@ -36,11 +37,11 @@ As you can see, as soon as a node is joined, it becomes equal to all
other nodes in the cluster, and the security of the cluster is
determined by the weakest node.
-Note that only the ssh key will allow other machines to run random
+Note that only the SSH key will allow other machines to run random
commands on this node; the RPC method will run only:
- well defined commands to create, remove, activate logical volumes,
drbd devices, start/stop instances, etc;
- - run ssh commands on other nodes in the cluster, again well-defined
+ - run SSH commands on other nodes in the cluster, again well-defined
- scripts under the /etc/ganeti/hooks directory
It is therefore important to make sure that the contents of the
@@ -52,21 +53,34 @@ Cluster issues
As told above, there are multiple ways of communication between cluster
nodes:
- - ssh-based, for high-volume traffic (image dumps) or for low-level
- command (restart the Ganeti node daemon)
- - python-twisted based, for the usual operation
- - DRBD traffic, for real-time disk replication traffic
+ - SSH-based, for high-volume traffic like image dumps or for low-level
+ command, e.g. restarting the Ganeti node daemon
+ - RPC communication between master and nodes
+ - DRBD real-time disk replication traffic
-The ssh traffic is protected (after the initial login to a new node) by
-the cluster-wide shared ssh key.
+The SSH traffic is protected (after the initial login to a new node) by
+the cluster-wide shared SSH key.
-The python-twisted traffic is secured by SSL and two pre-conditions: the
-client will refuse to connect to servers which don't have the
-cluster-wide shared SSL certificate, and server will not allow clients
-which don't have the cluster-wide shared secret.
+RPC communication between the master and nodes is protected using SSL/TLS
+encryption. Both the client and the server must have the cluster-widely
+shared SSL/TLS certificate and verify it when establishing the connection
+by comparing fingerprints. We decided not to use a CA to simplify the
+key handling.
-The DRBD traffic is not protected by anything. DRBD does not support
+The DRBD traffic is not protected by encryption. DRBD does not support
traffic encryption. It's therefore recommended to implement host-level
firewalling or to use a separate range of IP addresses for the DRBD
traffic (this is supported in Ganeti) which is not routed outside the
-cluster.
+cluster. DRBD connections are protected from connecting to random other
+machines by using a shared secret exchanged via RPC requests when
+starting the device.
+
+Remote API
+----------
+
+Starting with Ganeti 2.0, Remote API traffic is encrypted using SSL/TLS by
+default. It supports Basic authentication as per RFC2617.
+
+Paths for certificate, private key and CA files required for SSL/TLS will
+be set at source configure time. Symlinks or command line parameters may
+be used to use different files.
--
GitLab