Synnefo » snf-ganeti

candidate and then still have the power to compromise the whole cluster.

To mitigate this issue, we propose the following changes:

- Only if the ``master_capabability_rapi_modifiable`` switch is set to

  ``True``, it is possible to modify the master-capability flag of

  nodes.

With this setup, there are the following definitions of "potential

master candidates" depending on the rapi flag:

- If the rapi flag is set to ``True``, all cluster nodes are potential

  master candidates, because as described above, all of them can

  eventually be made master candidates via RAPI and thus security-wise,

On cluster initialization, the following steps are taken in

bootstrap.py:

- A public/private key pair is generated (as before), but only used

  by the first (and thus master) node. In particular, the private key

  never leaves the node.

Adding a new node will require the following steps.

In gnt_node.py:

- On the new node, a new public/private SSH key pair is generated.

- The public key of the new node is fetched (via SSH) to the master

  node and if it is a potential master candidate (see definition above),

  new node's ``authorized_keys`` file (also via SSH).

In LUNodeAdd in cmdlib/node.py:

- The LUNodeAdd determines whether or not the new node is a master

  candidate and in any case updates the cluster's configuration with the

  new nodes information. (This is not changed by the proposed design.)

  compromised RPC security should not compromise SSH security.

RPC call execution in noded (on master node):

- Check that the public key of the new node is in the

  ``ganeti_pub_keys`` file of the master node to make sure that no keys

  of nodes outside the Ganeti cluster and no keys that are not potential

RPC call to the master node's node daemon as for adding a node.

In the RPC call, noded will perform the following steps:

- Check that the public key of the node to be demoted is indeed in the

  ``ganeti_pub_keys`` file to avoid deleting ssh keys of machines that

  don't belong to the cluster (and thus potentially lock out the

When upgrading from a version that has the previous SSH setup to the one

proposed in this design, the upgrade procedure has to involve the

following steps in the post-upgrade hook:

- For all nodes, new SSH key pairs are generated.

- All nodes and their public keys are added to the ``ganeti_pub_keys``

  file and the file is copied to all nodes.

~~~~~~~~~~

These downgrading steps will be implemtented from 2.12 to 2.11:

- The master node's private/public key pair will be distributed to all

  nodes (via SSH) and the individual SSH keys will be backed up.

- The obsolete individual ssh keys will be removed from all nodes'