code.grnet.gr Git - ganeti-local/blob - SECURITY

   1 Security in Ganeti
   2 ~~~~~~~~~~~~~~~~~~
   3
   4 Ganeti was developed to run on internal, trusted systems. As such, the
   5 security model is all-or-nothing.
   6
   7 All the Ganeti code runs as root, because all the operations that Ganeti
   8 is doing require privileges: creating logical volumes, md arrays,
   9 starting instances, etc. Running as root does not mean setuid, but that
  10 you need to be root to run the cluster commands.
  11
  12 Host issues
  13 -----------
  14
  15 For a host on which the Ganeti software has been installed but which has
  16 not been joined in a cluster, there are no changes to the system.
  17
  18 For a host that has been joined to the cluster, there are very important
  19 changes:
  20   - the host will have its ssh host key replaced with the one of the
  21     cluster (which is the one the initial node had at the cluster
  22     creation)
  23   - root will have added to its authorized_keys file a public key which
  24     grants access to all other nodes in the cluster, and furthermore it
  25     will also get the private part of this key, which will allow it to
  26     login to the other nodes in the cluster (its previous private key
  27     will be backed up)
  28   - the Ganeti node daemon will accept RPC requests from any host which
  29     has the cluster shared secret, and the operations it will do as a
  30     result of these requests are:
  31       - running commands under the /etc/ganeti/hooks directory
  32       - creating DRBD disks between it and the IP it has been told
  33       - overwrite a defined list of files on the host
  34
  35 As you can see, as soon as a node is joined, it becomes equal to all
  36 other nodes in the cluster, and the security of the cluster is
  37 determined by the weakest node.
  38
  39 Note that only the ssh key will allow other machines to run random
  40 commands on this node; the RPC method will run only:
  41   - well defined commands to create, remove, activate logical volumes,
  42     DRBD disks, md arrays, start/stop instances, etc;
  43   - run ssh commands on other nodes in the cluster, again well-defined
  44   - scripts under the /etc/ganeti/hooks directory
  45
  46 It is therefore important to make sure that the contents of the
  47 /etc/ganeti/hooks directory is supervised and only trusted sources can
  48 populate it.
  49
  50 Cluster issues
  51 --------------
  52
  53 As told above, there are multiple ways of communication between cluster
  54 nodes:
  55   - ssh-based, for high-volume traffic (image dumps) or for low-level
  56     command (restart the Ganeti node daemon)
  57   - python-twisted based, for the usual operation
  58   - DRBD traffic, for real-time disk replication traffic
  59
  60 The ssh traffic is protected (after the initial login to a new node) by
  61 the cluster-wide shared ssh key.
  62
  63 The python-twisted traffic is secured by SSL and two pre-conditions: the
  64 client will refuse to connect to servers which don't have the
  65 cluster-wide shared SSL certificate, and server will not allow clients
  66 which don't have the cluster-wide shared secret.
  67
  68 The DRBD traffic is not protected by anything. DRBD does not support
  69 traffic encryption. It's therefore recommended to implement host-level
  70 firewalling or to use a separate range of IP addresses for the DRBD
  71 traffic (this is supported in Ganeti) which is not routed outside the
  72 cluster.