.. important: The ``cephx`` protocol does not address data encryption in transport
(e.g., SSL/TLS) or encryption at rest.
-For additional information, see our `Cephx Intro`_ and `ceph-authtool manpage`_.
+For additional information, see our `Cephx Intro`_, our `Cephx Configuration
+Reference`_ and `ceph-authtool manpage`_.
.. _Cephx Intro: ../auth-intro
.. _ceph-authtool manpage: ../../../man/8/ceph-authtool
=================
There are several important procedures you must follow to enable the ``cephx``
-protocol for your Ceph cluster and its daemons. First, you must generate a
-secret key for the default ``client.admin`` user so the administrator can
-execute Ceph commands. Second, you must generate a monitor secret key and
-distribute it to all monitors in the cluster. Finally, you can follow the
-remaining steps in `Enabling Cephx`_ to enable authentication.
+protocol for your Ceph cluster and its daemons:
+
+#. You must generate a secret key for the default ``client.admin`` user so the
+ administrator can execute Ceph commands.
+
+#. You must generate a monitor secret key and distribute it to all monitors in
+ the cluster.
+
+#. You must follow the remaining steps in `Enabling Cephx`_ to enable
+ authentication.
+
+See the `Cephx Configuration Reference`_ for additional details.
+
.. _client-admin-key:
sudo service ceph -a start
sudo service ceph -a restart
+
.. _disable-cephx:
Disabling Cephx
---------------
The following procedure describes how to disable Cephx. If your cluster
-environment is relatively safe, you can offset the computation expense of
-running authentication. **We do not recommend it.** However, it may be
-easier during setup and/or troubleshooting to temporarily disable authentication.
+environment is relatively safe, you can offset the computation expense of
+running authentication. **We do not recommend it.** However, it may be easier
+during setup and/or troubleshooting to temporarily disable authentication.
#. Disable ``cephx`` authentication for versions ``0.51`` and above by setting
the following options in the ``[global]`` section of your `Ceph configuration`_
Daemon Keyrings
---------------
-With the exception of the monitors, daemon keyrings are generated in
-the same way that user keyrings are. By default, the daemons store
-their keyrings inside their data directory. The default keyring
-locations, and the capabilities necessary for the daemon to function,
-are shown below.
+With the exception of the monitors, Ceph generates daemon keyrings in the same
+way that it generates user keyrings. By default, the daemons store their
+keyrings inside their data directory. The default keyring locations, and the
+capabilities necessary for the daemon to function, are shown below.
``ceph-mon``
You can override these locations, but it is not recommended.
+
Cephx Administration
====================
Cephx uses shared secret keys for authentication, meaning both the client and
-the monitor cluster have a copy of the client's secret key. The authentication
+the monitor cluster have a copy of the client's secret key. The authentication
protocol is such that both parties are able to prove to each other they have a
copy of the key without actually revealing it. This provides mutual
authentication, which means the cluster is sure the user possesses the secret
and production environments, you should create users and assign pool access to
the users.
+
.. _add-a-key:
Add a Key
Each server type has its own string. All capabilities are simply listed
in ``{type}`` and ``{capability}`` pairs on the command line::
- sudo ceph auth get-or-create-key client.{username} {daemon1} {cap1} {daemon2} {cap2} ...
+ sudo ceph auth get-or-create client.{username} {daemon1} {cap1} {daemon2} {cap2} ...
For example, to create a user ``client.foo`` with access 'rw' for
daemon type 'osd' and 'r' for daemon type 'mon'::
- sudo ceph auth get-or-create-key client.foo osd 'allow rw' mon 'allow r' > keyring.foo
+ sudo ceph auth get-or-create client.foo osd 'allow rw' mon 'allow r' > keyring.foo
.. note: User names are associated to user types, which include ``client``
``osd``, ``mon``, and ``mds``. In most cases, you will be
creating keys for ``client`` users.
+After you add a key to the cluster keyring, go to the relevant client(s) and
+copy the keyring from the cluster host to the client(s). ::
+
+ sudo scp {user}@{ceph-cluster-host}:/etc/ceph/ceph.keyring /etc/ceph/ceph.keyring
+
+.. tip:: Ensure the ``ceph.keyring`` file has appropriate permissions set
+ (e.g., ``chmod 644``) on your client machine.
+
+
.. _auth-delete-key:
Delete a Key
Where ``{daemon-type}`` is one of ``client``, ``osd``, ``mon``, or ``mds``,
and ``{ID|username}`` is the ID of the daemon or the username.
+After you delete a key from the cluster keyring, go to the relevant client(s) and
+copy the keyring from the cluster host to the client(s). ::
+
+ sudo scp {user}@{ceph-cluster-host}:/etc/ceph/ceph.keyring /etc/ceph/ceph.keyring
+
+.. tip:: Ensure the ``ceph.keyring`` file has appropriate permissions set
+ (e.g., ``chmod 644``) on your client machine.
+
+
+
List Keys in your Cluster
-------------------------
ceph --name client.foo --keyring /path/to/keyring health
ceph -n client.foo --keyring /path/to/keyring health
-
``--keyring``
of the enhanced authentication.
.. _Ceph configuration: ../../configuration/ceph-conf
+.. _Cephx Configuration Reference: ../../configuration/auth-config-ref
projects / ceph.git / commitdiff