code.grnet.gr Git - ganeti-local/blob - doc/security.rst

   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, drbd devices,
   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 not joined to a
  16 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
  21 - The host will have its SSH host key replaced with the one of the
  22   cluster (which is the one the initial node had at the cluster
  23   creation)
  24 - A new public key will be added to root's authorized_keys file,
  25   granting root access to all nodes of the cluster. The private part of
  26   the key is also distributed to all nodes. Old files are renamed.
  27 - Communication between nodes is encrypted using SSL/TLS. A common key
  28   and certificate combo is shared between all nodes of the cluster.  At
  29   this time, no CA is used.
  30 - The Ganeti node daemon will accept RPC requests from any host within
  31   the cluster with the correct certificate, and the operations it will
  32   do as a result of these requests are:
  33
  34   - running commands under the /etc/ganeti/hooks directory
  35   - creating DRBD disks between it and the IP it has been told
  36   - overwrite a defined list of files on the host
  37
  38 As you can see, as soon as a node is joined, it becomes equal to all
  39 other nodes in the cluster, and the security of the cluster is
  40 determined by the weakest node.
  41
  42 Note that only the SSH key will allow other machines to run random
  43 commands on this node; the RPC method will run only:
  44
  45 - well defined commands to create, remove, activate logical volumes,
  46   drbd devices, start/stop instances, etc;
  47 - run SSH commands on other nodes in the cluster, again well-defined
  48 - scripts under the /etc/ganeti/hooks directory
  49
  50 It is therefore important to make sure that the contents of the
  51 /etc/ganeti/hooks directory is supervised and only trusted sources can
  52 populate it.
  53
  54 Cluster issues
  55 --------------
  56
  57 As told above, there are multiple ways of communication between cluster
  58 nodes:
  59
  60 - SSH-based, for high-volume traffic like image dumps or for low-level
  61   command, e.g. restarting the Ganeti node daemon
  62 - RPC communication between master and nodes
  63 - DRBD real-time disk replication traffic
  64
  65 The SSH traffic is protected (after the initial login to a new node) by
  66 the cluster-wide shared SSH key.
  67
  68 RPC communication between the master and nodes is protected using SSL/TLS
  69 encryption. Both the client and the server must have the cluster-wide
  70 shared SSL/TLS certificate and verify it when establishing the connection
  71 by comparing fingerprints. We decided not to use a CA to simplify the
  72 key handling.
  73
  74 The DRBD traffic is not protected by encryption, as DRBD does not
  75 support this. It's therefore recommended to implement host-level
  76 firewalling or to use a separate range of IP addresses for the DRBD
  77 traffic (this is supported in Ganeti) which is not routed outside the
  78 cluster. DRBD connections are protected from connecting due to bugs to
  79 other machines, and from accepting connections from other machines, by
  80 using a shared secret, exchanged via RPC requests from the master to the
  81 nodes when configuring the device.
  82
  83 Master daemon
  84 -------------
  85
  86 The command-line tools to master daemon communication is done via an UNIX
  87 socket, whose permissions are reset to ``0600`` after listening but before
  88 serving requests. This permission-based protection is documented and works on
  89 Linux, but is not-portable; however, Ganeti doesn't work on non-Linux system at
  90 the moment.
  91
  92 Remote API
  93 ----------
  94
  95 Starting with Ganeti 2.0, Remote API traffic is encrypted using SSL/TLS by
  96 default. It supports Basic authentication as per RFC2617.
  97
  98 Paths for certificate, private key and CA files required for SSL/TLS will
  99 be set at source configure time. Symlinks or command line parameters may
 100 be used to use different files.