Revision 6884c0ca

b/doc/security.rst
1 1
Security in Ganeti
2
~~~~~~~~~~~~~~~~~~
2
==================
3 3

  
4 4
Ganeti was developed to run on internal, trusted systems. As such, the
5 5
security model is all-or-nothing.
......
17 17

  
18 18
For a host that has been joined to the cluster, there are very important
19 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
  - A new public key will be added to root's authorized_keys file, granting
24
    root access to all nodes of the cluster. The private part of the key
25
    is also distributed to all nodes. Old files are renamed.
26
  - Communication between nodes is encrypted using SSL/TLS. A common
27
    key and certificate combo is shared between all nodes of the cluster.
28
    At this time, no CA is used.
29
  - The Ganeti node daemon will accept RPC requests from any host within the
30
    cluster with the correct certificate, and the operations it will do as a
31
    result of these requests are:
32
      - running commands under the /etc/ganeti/hooks directory
33
      - creating DRBD disks between it and the IP it has been told
34
      - overwrite a defined list of files on the host
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
35 37

  
36 38
As you can see, as soon as a node is joined, it becomes equal to all
37 39
other nodes in the cluster, and the security of the cluster is
......
39 41

  
40 42
Note that only the SSH key will allow other machines to run random
41 43
commands on this node; the RPC method will run only:
42
  - well defined commands to create, remove, activate logical volumes,
43
    drbd devices, start/stop instances, etc;
44
  - run SSH commands on other nodes in the cluster, again well-defined
45
  - scripts under the /etc/ganeti/hooks directory
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
46 49

  
47 50
It is therefore important to make sure that the contents of the
48 51
/etc/ganeti/hooks directory is supervised and only trusted sources can
......
53 56

  
54 57
As told above, there are multiple ways of communication between cluster
55 58
nodes:
56
  - SSH-based, for high-volume traffic like image dumps or for low-level
57
    command, e.g. restarting the Ganeti node daemon
58
  - RPC communication between master and nodes
59
  - DRBD real-time disk replication traffic
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
60 64

  
61 65
The SSH traffic is protected (after the initial login to a new node) by
62 66
the cluster-wide shared SSH key.
63 67

  
64 68
RPC communication between the master and nodes is protected using SSL/TLS
65
encryption. Both the client and the server must have the cluster-widely
69
encryption. Both the client and the server must have the cluster-wide
66 70
shared SSL/TLS certificate and verify it when establishing the connection
67 71
by comparing fingerprints. We decided not to use a CA to simplify the
68 72
key handling.
69 73

  
70
The DRBD traffic is not protected by encryption. DRBD does not support
71
traffic encryption. It's therefore recommended to implement host-level
74
The DRBD traffic is not protected by encryption, as DRBD does not
75
support this. It's therefore recommended to implement host-level
72 76
firewalling or to use a separate range of IP addresses for the DRBD
73 77
traffic (this is supported in Ganeti) which is not routed outside the
74
cluster. DRBD connections are protected from connecting to random other
75
machines by using a shared secret exchanged via RPC requests when
76
starting the device.
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.
77 91

  
78 92
Remote API
79 93
----------

Also available in: Unified diff