Commit 3397d13e authored by Michael Hanselmann's avatar Michael Hanselmann
Browse files

Update security document for version 2.6



Quite some things were out of date. Some formatting was also updated.
Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
Reviewed-by: default avatarIustin Pop <iustin@google.com>
parent 4b945e1e
Security in Ganeti
==================
Documents Ganeti version 2.6
Ganeti was developed to run on internal, trusted systems. As such, the
security model is all-or-nothing.
All the Ganeti code runs as root, because all the operations that Ganeti
is doing require privileges: creating logical volumes, drbd devices,
starting instances, etc. Running as root does not mean setuid, but that
you need to be root to run the cluster commands.
Up to version 2.3 all Ganeti code ran as root. Since version 2.4 it is
possible to run all daemons except the node daemon as non-root users by
specifying user names and groups at build time. The node daemon
continues to require root privileges to create logical volumes, DRBD
devices, start instances, etc. Cluster commands can be run as root or by
users in a group specified at build time.
Host issues
-----------
......@@ -21,7 +25,7 @@ changes:
- The host will have its SSH host key replaced with the one of the
cluster (which is the one the initial node had at the cluster
creation)
- A new public key will be added to root's authorized_keys file,
- A new public key will be added to root's ``authorized_keys`` file,
granting root access to all nodes of the cluster. The private part of
the key is also distributed to all nodes. Old files are renamed.
- Communication between nodes is encrypted using SSL/TLS. A common key
......@@ -31,7 +35,7 @@ changes:
the cluster with the correct certificate, and the operations it will
do as a result of these requests are:
- running commands under the /etc/ganeti/hooks directory
- running commands under the ``/etc/ganeti/hooks`` directory
- creating DRBD disks between it and the IP it has been told
- overwrite a defined list of files on the host
......@@ -39,23 +43,23 @@ As you can see, as soon as a node is joined, it becomes equal to all
other nodes in the cluster, and the security of the cluster is
determined by the weakest node.
Note that only the SSH key will allow other machines to run random
commands on this node; the RPC method will run only:
Note that only the SSH key will allow other machines to run any command
on this node; the RPC method will run only:
- well defined commands to create, remove, activate logical volumes,
drbd devices, start/stop instances, etc;
- run SSH commands on other nodes in the cluster, again well-defined
- scripts under the /etc/ganeti/hooks directory
- run well-defined SSH commands on other nodes in the cluster
- scripts under the ``/etc/ganeti/hooks`` directory
It is therefore important to make sure that the contents of the
/etc/ganeti/hooks directory is supervised and only trusted sources can
populate it.
``/etc/ganeti/hooks`` directory is supervised and only trusted sources
can populate it.
Cluster issues
--------------
As told above, there are multiple ways of communication between cluster
nodes:
As mentioned above, there are multiple ways of communication between
cluster nodes:
- SSH-based, for high-volume traffic like image dumps or for low-level
command, e.g. restarting the Ganeti node daemon
......@@ -74,17 +78,18 @@ simplify the key handling.
The DRBD traffic is not protected by encryption, as DRBD does not
support this. It's therefore recommended to implement host-level
firewalling or to use a separate range of IP addresses for the DRBD
traffic (this is supported in Ganeti) which is not routed outside the
cluster. DRBD connections are protected from connecting due to bugs to
other machines, and from accepting connections from other machines, by
using a shared secret, exchanged via RPC requests from the master to the
nodes when configuring the device.
traffic (this is supported in Ganeti through the use of a secondary
interface) which is not routed outside the cluster. DRBD connections are
protected from erroneous connections to other machines (as may happen
due to software issues), and from accepting connections from other
machines, by using a shared secret, exchanged via RPC requests from the
master to the nodes when configuring the device.
Master daemon
-------------
The command-line tools to master daemon communication is done via an
UNIX socket, whose permissions are reset to ``0600`` after listening but
The command-line tools to master daemon communication is done via a
UNIX socket, whose permissions are reset to ``0660`` after listening but
before serving requests. This permission-based protection is documented
and works on Linux, but is not-portable; however, Ganeti doesn't work on
non-Linux system at the moment.
......@@ -113,15 +118,15 @@ KVM Security
------------
When running KVM instances under Ganeti three security models ara
available: 'none', 'user' and 'pool'.
available: "none", "user" and "pool".
Under security model 'none' instances run by default as root. This means
Under security model "none" instances run by default as root. This means
that, if an instance gets jail broken, it will be able to own the host
node, and thus the ganeti cluster. This is the default model, and the
only one available before Ganeti 2.1.2.
Under security model 'user' an instance is run as the user specified by
the hypervisor parameter 'security_domain'. This makes it easy to run
Under security model "user" an instance is run as the user specified by
the hypervisor parameter "security_domain". This makes it easy to run
all instances as non privileged users, and allows one to manually
allocate specific users to specific instances or sets of instances. If
the specified user doesn't have permissions a jail broken instance will
......@@ -129,7 +134,7 @@ need some local privilege escalation before being able to take over the
node and the cluster. It's possible though for a jail broken instance to
affect other ones running under the same user.
Under security model 'pool' a global cluster-level uid pool is used to
Under security model "pool" a global cluster-level uid pool is used to
start each instance on the same node under a different user. The uids in
the cluster pool can be set with ``gnt-cluster init`` and ``gnt-cluster
modify``, and must correspond to existing users on all nodes. Ganeti
......@@ -137,7 +142,7 @@ will then allocate one to each instance, as needed. This way a jail
broken instance won't be able to affect any other. Since the users are
handed out by ganeti in a per-node randomized way, in this mode there is
no way to make sure a particular instance is always run as a certain
user. Use mode 'user' for that.
user. Use mode "user" for that.
In addition to these precautions, if you want to avoid instances sending
traffic on your node network, you can use an iptables rule such as::
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment