root / doc / security.rst @ ca9ccea8
History | View | Annotate | Download (4 kB)
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. |