5
Default users and pools are suitable for initial testing purposes. For test bed
6
and production environments, you should create users and assign pool access to
9
Enabling Authentication
10
-----------------------
11
In the ``[global]`` settings of your ``ceph.conf`` file, you must enable
12
authentication for your cluster. ::
15
auth supported = cephx
17
The valid values are ``cephx`` or ``none``. If you specify ``cephx``,
18
Ceph will look for the keyring in the default search path, which
19
includes ``/etc/ceph/keyring``. You can override this location by
20
adding a ``keyring`` option in the ``[global]`` section of your
21
``ceph.conf`` file, but this is not recommended.
23
The ``client.admin`` Key
24
------------------------
26
By default, each Ceph command you execute on the command line assumes
27
that you are the ``client.admin`` default user. When running Ceph with
28
``cephx`` enabled, you need to have a ``client.admin`` key to run
31
.. important: To continue to run Ceph commands on the command line with
32
``cephx`` enabled, you need to create a key for the ``client.admin``
33
user, and create a secret file under ``/etc/ceph``.
35
The following command will generate and register a ``client.admin``
36
key on the monitor with admin capabilities and write it to a keyring
37
on the local file system. If the key already exists, its current
38
value will be returned.
42
sudo ceph auth get-or-create client.admin mds 'allow' osd 'allow *' mon 'allow *' > /etc/ceph/keyring
47
Keys enable a specific user to access the monitor, metadata server and
48
cluster according to capabilities assigned to the key. Capabilities are
49
simple strings specifying some access permissions for a given server type.
50
Each server type has its own string. All capabilities are simply listed
51
in ``{type}`` and ``{capability}`` pairs on the command line::
53
sudo ceph auth get-or-create client.{username} {daemon1} {cap1} {daemon2} {cap2} ...
55
For example, to create a user ``client.foo`` with access 'rw' for
56
daemon type 'osd' and 'r' for daemon type 'mon'::
58
sudo ceph auth get-or-create client.foo osd rw mon r > keyring.foo
60
.. note: User names are associated to user types, which include ``client``
61
``admin``, ``osd``, ``mon``, and ``mds``. In most cases, you will be
62
creating keys for ``client`` users.
65
List Keys in your Cluster
66
-------------------------
68
To list the keys registered in your cluster::
76
With the exception of the monitors, daemon keyrings are generated in
77
the same way that user keyrings are. By default, the daemons store
78
their keyrings inside their data directory. The default keyring
79
locations, and the capabilities necessary for the daemon to function,
82
+-----------+---------------------------+---------------------------------------------+
83
| Daemon | Default keyring location | Default caps |
84
+===========+===========================+=============================================+
85
| ceph-mon | $mon_data/keyring | n/a |
86
+-----------+---------------------------+---------------------------------------------+
87
| ceph-osd | $osd_data/keyring | mon 'allow rwx' osd 'allow *' |
88
+-----------+---------------------------+---------------------------------------------+
89
| ceph-mds | $mds_data/keyring | mds 'allow rwx' mds 'allow *' osd 'allow *' |
90
+-----------+---------------------------+---------------------------------------------+
91
| radosgw | $rgw_data/keyring | mon 'allow r' osd 'allow rwx' |
92
+-----------+---------------------------+---------------------------------------------+
94
Note that the monitor keyring contains a key but no capabilities, and
95
is not part of the cluster auth database.
97
The daemon data directory locations default to directories of the form::
99
/var/lib/ceph/$daemontype/$cluster-$id
101
For example, ``osd.12`` would be::
103
/var/lib/ceph/osd/ceph-12
105
You can override these locations, but it is not recommended.
107
The monitor key can be created with ``ceph-authtool`` command, and
108
must be identical across all monitors::
110
sudo ceph-authtool {keyring} --create-keyring --gen-key -n mon.
added
removed
doc/config-cluster/authentication.rst
