Revision 28cc354f
b/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, as the version of DRBD we |
|
69 |
require (0.7) does not have any protections. It's therefore recommended |
|
70 |
to implement host-level firewalling or to use a separate range of IP |
|
71 |
addresses for the DRBD traffic (this is supported in Ganeti) which is |
|
72 |
not routed outside the cluster. |
Also available in: Unified diff