X-Git-Url: https://code.grnet.gr/git/ganeti-local/blobdiff_plain/73100cf54f5e1245d7862a52085fe722d911adc0..c8fcde472922e4ee664d904e0bf1a583f1d5040d:/doc/security.rst diff --git a/doc/security.rst b/doc/security.rst index 6c0309e..e907c44 100644 --- a/doc/security.rst +++ b/doc/security.rst @@ -1,5 +1,5 @@ Security in Ganeti -~~~~~~~~~~~~~~~~~~ +================== Ganeti was developed to run on internal, trusted systems. As such, the security model is all-or-nothing. @@ -17,21 +17,23 @@ 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 - cluster (which is the one the initial node had at the cluster - creation) - - 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 - - overwrite a defined list of files on the host + +- 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) +- 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 + - overwrite a defined list of files on the host 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 @@ -39,10 +41,11 @@ determined by the weakest node. 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 - - scripts under the /etc/ganeti/hooks directory + +- 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 +- scripts under the /etc/ganeti/hooks directory It is therefore important to make sure that the contents of the /etc/ganeti/hooks directory is supervised and only trusted sources can @@ -53,27 +56,38 @@ Cluster issues As told above, there are multiple ways of communication between cluster nodes: - - 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 + +- 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. RPC communication between the master and nodes is protected using SSL/TLS -encryption. Both the client and the server must have the cluster-widely +encryption. Both the client and the server must have the cluster-wide 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 encryption. DRBD does not support -traffic encryption. It's therefore recommended to implement host-level +The DRBD traffic is not protected by encryption, as DRBD does not +support this. 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. DRBD connections are protected from connecting to random other -machines by using a shared secret exchanged via RPC requests when -starting the device. +cluster. DRBD connections are protected from connecting due to bugs to +other machines, and from accepting connections from other machines, by +using a shared secret, exchanged via RPC requests from the master to the +nodes when configuring the device. + +Master daemon +------------- + +The command-line tools to master daemon communication is done via an UNIX +socket, whose permissions are reset to ``0600`` after listening but before +serving requests. This permission-based protection is documented and works on +Linux, but is not-portable; however, Ganeti doesn't work on non-Linux system at +the moment. Remote API ----------