root / SECURITY @ 2ec08468
History | View | Annotate | Download (3.1 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, 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. |