X-Git-Url: https://code.grnet.gr/git/ganeti-local/blobdiff_plain/f1d243bd85f1f168cb8746b6c2856ee72a9c008f..fdbdeaa3e9039a9ef449a7fc9d0c477f921ad796:/doc/security.rst

diff --git a/doc/security.rst b/doc/security.rst
index 70d1d95..f81c0c7 100644
--- a/doc/security.rst
+++ b/doc/security.rst
@@ -1,17 +1,19 @@
 Security in Ganeti
 ==================
 
-Documents Ganeti version 2.6
+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
 -----------
@@ -50,10 +52,38 @@ on this node; the RPC method will run only:
   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
 --------------
@@ -94,6 +124,42 @@ 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.
 
+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
 ----------