Revision 4fbe765c SECURITY
b/SECURITY | ||
---|---|---|
12 | 12 |
Host issues |
13 | 13 |
----------- |
14 | 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.
|
|
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 | 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
|
|
20 |
- The host will have its SSH host key replaced with the one of the
|
|
21 | 21 |
cluster (which is the one the initial node had at the cluster |
22 | 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 |
|
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 |
|
30 | 31 |
result of these requests are: |
31 | 32 |
- running commands under the /etc/ganeti/hooks directory |
32 | 33 |
- creating DRBD disks between it and the IP it has been told |
... | ... | |
36 | 37 |
other nodes in the cluster, and the security of the cluster is |
37 | 38 |
determined by the weakest node. |
38 | 39 |
|
39 |
Note that only the ssh key will allow other machines to run random
|
|
40 |
Note that only the SSH key will allow other machines to run random
|
|
40 | 41 |
commands on this node; the RPC method will run only: |
41 | 42 |
- well defined commands to create, remove, activate logical volumes, |
42 | 43 |
drbd devices, start/stop instances, etc; |
43 |
- run ssh commands on other nodes in the cluster, again well-defined
|
|
44 |
- run SSH commands on other nodes in the cluster, again well-defined
|
|
44 | 45 |
- scripts under the /etc/ganeti/hooks directory |
45 | 46 |
|
46 | 47 |
It is therefore important to make sure that the contents of the |
... | ... | |
52 | 53 |
|
53 | 54 |
As told above, there are multiple ways of communication between cluster |
54 | 55 |
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
|
|
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 |
|
60 |
The ssh traffic is protected (after the initial login to a new node) by
|
|
61 |
the cluster-wide shared ssh key.
|
|
61 |
The SSH traffic is protected (after the initial login to a new node) by
|
|
62 |
the cluster-wide shared SSH key.
|
|
62 | 63 |
|
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. |
|
64 |
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 |
|
66 |
shared SSL/TLS certificate and verify it when establishing the connection |
|
67 |
by comparing fingerprints. We decided not to use a CA to simplify the |
|
68 |
key handling. |
|
67 | 69 |
|
68 |
The DRBD traffic is not protected by anything. DRBD does not support
|
|
70 |
The DRBD traffic is not protected by encryption. DRBD does not support
|
|
69 | 71 |
traffic encryption. It's therefore recommended to implement host-level |
70 | 72 |
firewalling or to use a separate range of IP addresses for the DRBD |
71 | 73 |
traffic (this is supported in Ganeti) which is not routed outside the |
72 |
cluster. |
|
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. |
|
77 |
|
|
78 |
Remote API |
|
79 |
---------- |
|
80 |
|
|
81 |
Starting with Ganeti 2.0, Remote API traffic is encrypted using SSL/TLS by |
|
82 |
default. It supports Basic authentication as per RFC2617. |
|
83 |
|
|
84 |
Paths for certificate, private key and CA files required for SSL/TLS will |
|
85 |
be set at source configure time. Symlinks or command line parameters may |
|
86 |
be used to use different files. |
Also available in: Unified diff