Security in Ganeti
==================
-Documents Ganeti version 2.7
+Documents Ganeti version 2.9
Ganeti was developed to run on internal, trusted systems. As such, the
security model is all-or-nothing.
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.
+possible to run all daemons except the node daemon and the monitoring 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. The monitoring daemon requires root
+privileges in order to be able to access and present information that are only
+avilable to root (such as the output of the ``xm`` command of Xen).
Host issues
-----------
drbd devices, start/stop instances, etc;
- run well-defined SSH commands on other nodes in the cluster
- scripts under the ``/etc/ganeti/hooks`` directory
+- scripts under the ``/etc/ganeti/restricted-commands`` directory, if
+ this feature has been enabled at build time (see below)
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`` and ``/etc/ganeti/restricted-commands``
+directories are supervised and only trusted sources can populate them.
+
+Restricted commands
+~~~~~~~~~~~~~~~~~~~
+
+The restricted commands feature is new in Ganeti 2.7. It enables the
+administrator to run any commands in the
+``/etc/ganeti/restricted-commands`` directory, if the feature has been
+enabled at build time, subject to the following restrictions:
+
+- No parameters may be passed
+- No absolute or relative path may be passed, only a filename
+- The ``/etc/ganeti/restricted-commands`` directory must
+ be owned by root:root and have mode 0755 or stricter
+- Executables must be regular files or symlinks, and must be executable
+ by root:root
+
+Note that it's not possible to list the contents of the directory, and
+there is an intentional delay when trying to execute a non-existing
+command (to slow-down dictionary attacks).
+
+Since for Ganeti itself this functionality is not needed, and is only
+provided as a way to help administrate or recover nodes, it is a local
+site decision whether to enable or not the restricted commands feature.
+
+By default, this feature is disabled.
+
Cluster issues
--------------
and works on Linux, but is not-portable; however, Ganeti doesn't work on
non-Linux system at the moment.
+Conf daemon
+-----------
+
+In Ganeti 2.8, the ``confd`` daemon (if enabled at build time), serves
+both network-originated queries (about the static configuration) and
+local (UNIX socket) queries (about the run-time configuration; answering
+these means talking to other cluster nodes, which makes use of the
+internal RPC SSL certificate). This makes it a bit more sensitive to
+bugs (a remote attacker could get direct access to the intra-cluster
+RPC), so to harden security it's recommended to:
+
+- disable confd at build time if it's not needed in your setup
+- otherwise, configure Ganeti (at build time) to use separate users, so
+ that the confd daemon doesn't also have access to the server SSL/TLS
+ certificates.
+
+NB: the second suggestion is not valid since Ganeti 2.8.0~beta1, because confd
+needs access to the certificate in order to communicate on the network.
+This will be fixed when the planned split of the two functionalities
+(local/remote querying) of confd into two separate daemons will take place,
+in a future Ganeti version.
+
+Monitoring daemon
+-----------------
+
+The monitoring daemon provides information about the status and the
+performance of the cluster over HTTP.
+It is currently unencrypted and non-authenticated, therefore it is strongly
+advised to set proper firewalling rules to prevent unwanted access.
+
+The monitoring daemon runs as root, because it needs to be able to access
+privileged information (such as the state of the instances as provided by
+the Xen hypervisor). Nevertheless, the security implications are mitigated
+by the fact that the agent only provides reporting functionalities,
+without the ability to actually modify the state of the cluster.
+
Remote API
----------
projects / ganeti-local / blobdiff