mirror of
https://github.com/ceph/ceph
synced 2024-12-24 20:33:27 +00:00
32b44cb4ae
Signed-off-by: John Wilkins <john.wilkins@inktank.com>
182 lines
6.1 KiB
ReStructuredText
182 lines
6.1 KiB
ReStructuredText
================
|
|
Authentication
|
|
================
|
|
|
|
Ceph provides two authentication modes:
|
|
|
|
- **None:** Any user can access data without authentication.
|
|
- **Cephx**: Ceph requires user authentication in a manner similar to Kerberos.
|
|
|
|
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
|
|
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
|
|
key, and the user is sure that the cluster has a copy of the secret key.
|
|
|
|
Default users and pools are suitable for initial testing purposes. For test bed
|
|
and production environments, you should create users and assign pool access to
|
|
the users.
|
|
|
|
.. important:: The ``cephx`` protocol supports authentication only. Cephx
|
|
currently **does not** address man-in-the-middle attacks. We will address
|
|
this in an upcoming release.
|
|
|
|
.. important: The ``cephx`` protocol does not address data encryption in transport
|
|
(e.g., SSL/TLS) or encryption at rest.
|
|
|
|
|
|
|
|
Enabling Authentication
|
|
=======================
|
|
|
|
If you do not turn on authentication, it will be turned off by default. If you
|
|
specify ``cephx``, Ceph will look for the keyring in the default search path,
|
|
which includes ``/etc/ceph/keyring``. You can override this location by adding
|
|
a ``keyring`` option in the ``[global]`` section of your ``ceph.conf`` file, but
|
|
this is not recommended.
|
|
|
|
To enable ``cephx`` on a cluster without authentication:
|
|
|
|
#. Create a ``client.admin`` key, and save a copy of the key for your client host::
|
|
|
|
ceph auth get-or-create client.admin mon 'allow *' mds 'allow *' osd 'allow *' -o /etc/ceph/keyring
|
|
|
|
**Warning:** This will clobber any existing ``/etc/ceph/keyring`` file. Be careful!
|
|
|
|
#. Generate a secret monitor ``mon.`` key::
|
|
|
|
ceph-authtool --create --gen-key -n mon. /tmp/monitor-key
|
|
|
|
#. Copy the mon keyring into a ``keyring`` file in every monitor's ``mon data`` directory::
|
|
|
|
cp /tmp/monitor-key /var/lib/ceph/mon/ceph-a/keyring
|
|
|
|
#. Generate a secret key for every OSD, where ``{$id}`` is the OSD number::
|
|
|
|
ceph auth get-or-create osd.{$id} mon 'allow rwx' osd 'allow *' -o /var/lib/ceph/osd/ceph-{$id}/keyring
|
|
|
|
#. Generate a secret key for every MDS, where ``{$id}`` is the MDS letter::
|
|
|
|
ceph auth get-or-create mds.{$id} mon 'allow rwx' osd 'allow *' mds 'allow *' -o /var/lib/ceph/mds/ceph-{$id}/keyring
|
|
|
|
#. Enable ``cephx`` authentication for versions ``0.51`` and above by setting
|
|
the following options in the ``[global]`` section of your ``ceph.conf``::
|
|
|
|
auth cluster required = cephx
|
|
auth service required = cephx
|
|
auth client required = cephx
|
|
|
|
#. Or, enable ``cephx`` authentication for versions ``0.50`` and below by
|
|
setting the following option in the ``[global]`` section of your ``ceph.conf``::
|
|
|
|
auth supported = cephx
|
|
|
|
.. deprecated:: 0.51
|
|
|
|
|
|
The ``client.admin`` Key
|
|
========================
|
|
|
|
By default, each Ceph command you execute on the command line assumes
|
|
that you are the ``client.admin`` default user. When running Ceph with
|
|
``cephx`` enabled, you need to have a ``client.admin`` key to run
|
|
``ceph`` commands.
|
|
|
|
.. important: To continue to run Ceph commands on the command line with
|
|
``cephx`` enabled, you need to create a key for the ``client.admin``
|
|
user, and create a secret file under ``/etc/ceph``.
|
|
|
|
The following command will generate and register a ``client.admin``
|
|
key on the monitor with admin capabilities and write it to a keyring
|
|
on the local file system. If the key already exists, its current
|
|
value will be returned. ::
|
|
|
|
sudo ceph auth get-or-create client.admin mds 'allow' osd 'allow *' mon 'allow *' > /etc/ceph/keyring
|
|
|
|
Generate a Key
|
|
==============
|
|
|
|
Keys enable a specific user to access the monitor, metadata server and
|
|
cluster according to capabilities assigned to the key. Capabilities are
|
|
simple strings specifying some access permissions for a given server type.
|
|
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} ...
|
|
|
|
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 rw mon r > keyring.foo
|
|
|
|
.. note: User names are associated to user types, which include ``client``
|
|
``admin``, ``osd``, ``mon``, and ``mds``. In most cases, you will be
|
|
creating keys for ``client`` users.
|
|
|
|
|
|
List Keys in your Cluster
|
|
=========================
|
|
|
|
To list the keys registered in your cluster::
|
|
|
|
sudo ceph auth list
|
|
|
|
|
|
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.
|
|
|
|
``ceph-mon``
|
|
|
|
:Location: ``$mon_data/keyring``
|
|
:Capabilities: N/A
|
|
|
|
``ceph-osd``
|
|
|
|
:Location: ``$osd_data/keyring``
|
|
:Capabilities: ``mon 'allow rwx' osd 'allow *'``
|
|
|
|
``ceph-mds``
|
|
|
|
:Location: ``$mds_data/keyring``
|
|
:Capabilities: ``mds 'allow rwx' mds 'allow *' osd 'allow *'``
|
|
|
|
``radosgw``
|
|
|
|
:Location: ``$rgw_data/keyring``
|
|
:Capabilities: mon 'allow r' osd 'allow rwx'
|
|
|
|
|
|
Note that the monitor keyring contains a key but no capabilities, and
|
|
is not part of the cluster ``auth`` database.
|
|
|
|
The daemon data directory locations default to directories of the form::
|
|
|
|
/var/lib/ceph/$type/$cluster-$id
|
|
|
|
For example, ``osd.12`` would be::
|
|
|
|
/var/lib/ceph/osd/ceph-12
|
|
|
|
You can override these locations, but it is not recommended.
|
|
|
|
Monitor Keyrings
|
|
================
|
|
|
|
Use the ``ceph-authtool`` command to generate a monitor key and kerying. ::
|
|
|
|
sudo ceph-authtool {keyring} --create-keyring --gen-key -n mon.
|
|
|
|
A cluster with multiple monitors must have identical keyrings for all
|
|
monitors. So you must copy the keyring to each monitor host under the
|
|
following directory::
|
|
|
|
/var/lib/ceph/mon/$cluster-$id
|
|
|