CL260 - ch04s05

Bookmark this page

Managing Ceph Authentication

Objectives

After completing this section, you should be able to describe Cephx and configure user authentication and authorization for Ceph clients.

Authenticating Users

Red Hat Ceph Storage uses the cephx protocol to authorize communication between clients, applications, and daemons in the cluster. The cephx protocol is based on shared secret keys.

The installation process enables cephx by default, so that the cluster requires user authentication and authorization by all client applications.

Ceph uses user accounts for several purposes:

For internal communication between Ceph daemons.
For client applications accessing the cluster through the librados library.
For cluster administrators.

Accounts used by Ceph daemons have names that match their associated daemon: osd.1 or mgr.serverc and are created during the installation.

Accounts used by client applications that use librados have names with the client. prefix. For example, when integrating OpenStack with Ceph, it is common to create a dedicated client.openstack user account. For the Ceph Object Gateway, the installation creates a dedicated client.rgw.hostname user account. Developers creating custom software on top of librados should create dedicated accounts with appropriate capabilities.

Administrator account names also have the client. prefix. These accounts are used when running commands such as ceph and rados. The installer creates the superuser account, client.admin, with capabilities that allow the account to access everything and to modify the cluster configuration. Ceph uses the client.admin account to run administrative commands, unless you explicitly specify a user name with the --name or --id options.

You can set the CEPH_ARGS environment variable to define parameters such as the cluster name or the ID of the user.

[ceph: root@node /]# export CEPH_ARGS="--id cephuser"

End users of a Ceph-aware application do not have an account on the Ceph cluster. Rather, they access the application, which then accesses Ceph on their behalf. From the Ceph point of view, the application is the client. The application might provide its own user authentication through other mechanisms.

SectionFigure 4.12: User authentication for Ceph applications provides an overview of how an application can provide its own user authentication.

Figure 4.12: User authentication for Ceph applications

The Ceph Object Gateway has its own user database to authenticate Amazon S3 and Swift users, but uses the client.rgw.hostname account to access the cluster.

The Key-ring File

For authentication, clients are configured with a Ceph user name and a key-ring file containing the user's secret key. Ceph generates the key-ring file for each user account when it is created. However, you must copy this file to each client system or application server on which it is needed.

On these client systems, librados uses the keyring parameter from the /etc/ceph/ceph.conf configuration file to locate the key-ring file. Its default value is /etc/ceph/$cluster.$name.keyring. For example, for the client.openstack account, the key-ring file is /etc/ceph/ceph.client.openstack.keyring.

The key-ring file stores the secret key as plain text. Protect the file with appropriate Linux file permissions for access only by authorized Linux users. Only deploy a Ceph user's key-ring file on systems that need it for authentication.

Transmitting Secret Keys

The cephx protocol does not transmit the shared secret keys as plain text. Instead, a client requests a session key from a Monitor. The Monitor encrypts the session key with the client's shared secret key and provides the session key to the client. A client decrypts the session key and requests a ticket from a Monitor to authenticate to cluster daemons. This is similar to the Kerberos protocol, with a cephx key-ring file being comparable to a Kerberos keytab file.

A more detailed discussion of the protocol is available from the upstream Ceph project's documentation at High Availability Authentication.

Configuring User Authentication

Using command-line tools such as ceph, rados, and rbd, administrators can specify the user account and the key-ring file by using the --id and --keyring options. When not specified, commands authenticate as the client.admin user.

In this example, the ceph command authenticates as client.operator3 to list the available pools:

[ceph: root@node /]# ceph --id operator3 osd lspools
1 myfirstpool
2 mysecondpool

Important

Do not include the client. prefix when using the --id option. The --id option automatically assumes that client. prefix. Alternatively, the --name option requires the client. prefix.

If you store the key-ring file in its default location, you do not need the --keyring option. The cephadm shell automatically mounts the key-ring from the /etc/ceph/ directory.

Configuring User Authorization

When you create a new user account, grant cluster permissions sufficient to authorize the user's cluster tasks. Permissions within cephx are known as capabilities, and you grant them by daemon type (mon, osd, mgr, or mds.)

Use capabilities to restrict or provide access to data in a pool, a pool's namespace, or a set of pools based on application tags. Capabilities also allow the daemons in the cluster to interact with each other.

Cephx Capabilities

Within cephx, for each daemon type, several capabilities are available:

r grants read access. Each user account should have at least read access on the Monitors to be able to retrieve the CRUSH map.
w grants write access. Clients need write access to store and modify objects on OSDs. For Managers (MGRs), w grants the right to enable or disable modules.
x grants authorization to execute extended object classes. This allows clients to perform extra operations on objects such as setting locks with rados lock get or listing RBD images with rbd list.
* grants full access.
class-read and class-write are subsets of x. You typically use them on RBD pools.

This example creates the formyapp1 user account, and grants the capability to store and retrieve objects from any pool:

[ceph: root@node /]# ceph auth get-or-create client.formyapp1 \
 mon 'allow r' osd 'allow rw'

Using Profiles to Set Capabilities

cephx offers predefined capability profiles. When creating user accounts, utilize profiles to simplify configuration of user access rights.

This example utilizes the rbd profile to define the access rights for the new forrbd user account. A client application can use this account for block-based access to Ceph storage using a RADOS Block Device.

[ceph: root@node /]# ceph auth get-or-create client.forrbd \
 mon 'profile rbd' osd 'profile rbd'

The rbd-read-only profile works the same way but grants read-only access. Ceph utilizes other existing profiles for internal communication between daemons. You cannot create your own profiles, Ceph defines them internally.

The following table lists Ceph capabilities on a default installation.

Capability	Description
`allow`	Precedes access settings for a daemon.
`r`	Gives the user read access. Required with monitors to retrieve the CRUSH map.
`w`	Gives the user write access to objects.
`x`	Gives the user the capability to call class methods (that is, both read and write) and to conduct authentication operations on monitors.
`class-read`	Gives the user the capability to call class read methods. Subset of x.
`class-write`	Gives the user the capability to call class write methods. Subset of x.
`*`	Gives the user read, write and execute permissions for a particular daemon or pool, and the ability to execute admin commands.
`profile osd`	Gives a user permissions to connect as an OSD to other OSDs or monitors. Conferred on OSDs to enable OSDs to handle replication heartbeat traffic and status reporting.
`profile bootstrap-osd`	Gives a user permissions to bootstrap an OSD, so that they have permissions to add keys when bootstrapping an OSD.
`profile rbd`	Gives a user read-write access to the Ceph Block Devices.
`profile rbd-read-only`	Gives a user read-only access to the Ceph Block Devices.

Restricting Access

Restrict user OSD permissions such that users can only access the pools they need. This example creates the formyapp2 user and limits their access to read and write on the myapp pool:

[ceph: root@node /]# ceph auth get-or-create client.formyapp2 \
 mon 'allow r' osd 'allow rw pool=myapp'

If you do not specify a pool when you configure capabilities, then Ceph sets them on all existing pools.

The cephx mechanism can restrict access to objects by other means:

By object name prefix. The following example restricts access to only those objects whose names start with pref in any pool.
```
[ceph: root@node /]# ceph auth get-or-create client.formyapp3 \
 mon 'allow r' osd 'allow rw object_prefix pref'
```
By namespace. Implement namespaces to logically group objects within a pool. You can then restrict user accounts to objects belonging to a specific namespace:
```
[ceph: root@node /]# ceph auth get-or-create client.designer \
 mon 'allow r' osd 'allow rw namespace=photos'
```

By path. The Ceph File System (CephFS) utilizes this method to restrict access to specific directories. This example creates a new user account, webdesigner, that can access only the /webcontent directory and its contents:

[ceph: root@node /]# ceph fs authorize cephfs client.webdesigner /webcontent rw
[ceph: root@node /]# ceph auth get client.webdesigner
exported keyring for client.webdesigner
[client.webdesigner]
       key = AQBrVE9aNwoEGRAApYR6m71ECRzUlLpp4wEJkw==
        caps mds = "allow rw path=/webcontent"
        caps mon = "allow r"
        caps osd = "allow rw pool=cephfs_data"

By Monitor command. This method restricts administrators to a specific list of commands. The following example creates the operator1 user account and limits its access to two commands:
```
[ceph: root@node /]# ceph auth get-or-create client.operator1 \
 mon 'allow r, allow command "auth get-or-create", allow command "auth list"'
```

User Management

To list existing user accounts, run the ceph auth list command:

[ceph: root@node /]# ceph auth list
...output omitted...
osd.0
      key: AQBW6Tha5z6OIhAAMQ7nY/4MogYecxKqQxX1sA==
      caps: [mgr] allow profile osd
      caps: [mon] allow profile osd
      caps: [osd] allow *
client.admin
      key: AQCi6Dhajw7pIRAA/ECkwyipx2/raLWjgbklyA==
      caps: [mds] allow *
      caps: [mgr] allow *
      caps: [mon] allow *
      caps: [osd] allow *
...output omitted...

To get the details of a specific account, use the ceph auth get command:

[ceph: root@node /]# ceph auth get client.admin
exported keyring for client.admin
[client.admin]
      key = AQCi6Dhajw7pIRAA/ECkwyipx2/raLWjgbklyA==
      caps mds = "allow *"
      caps mgr = "allow *"
      caps mon = "allow *"
      caps osd = "allow *"

You can print the secret key:

[ceph: root@node /]# ceph auth print-key client.admin
AQCi6Dhajw7pIRAA/ECkwyipx2/raLWjgbklyA==

To export and import user accounts, run the ceph auth export and ceph auth import commands:

[ceph: root@node /]# ceph auth export client.operator1 > ~/operator1.export
[ceph: root@node /]# ceph auth import -i ~/operator1.export

Creating New User Accounts

The ceph auth get-or-create command creates a new user account and generates its secret key. The command prints this key to stdout by default, so it is common to add the -o option to save standard output to a key-ring file.

This example creates the app1 user account with read and write access to all pools, and stores the key-ring file in /etc/ceph/ceph.client.app1.keyring:

[ceph: root@node /]# ceph auth get-or-create client.app1 \
 mon 'allow r' osd 'allow rw' -o /etc/ceph/ceph.client.app1.keyring

Authentication requires the key-ring file, so you must copy the file to all client systems that operate with this new user account.

Modifying User Capabilities

Modify the capabilities of a user account with the ceph auth caps command.

This example modifies the app1 user account capabilities on OSDs to allow only read and write access to the myapp pool:

[ceph: root@node /]# ceph auth caps client.app1 mon 'allow r' \
 osd 'allow rw pool=myapp'
    updated caps for client.app1

The ceph auth caps command overwrites existing capabilities When using this command, you must specify the full set of capabilities for all daemons, not only those you want to modify. Define an empty string to remove all capabilities:

[ceph: root@node /]# ceph auth caps client.app1 osd ''
    updated caps for client.app1

Deleting User Accounts

The ceph auth del command deletes a user account:

[ceph: root@node /]# ceph auth del client.app1
updated

You can then remove the associated key-ring file.

References

For more information, refer to the Ceph User Management chapter in the Red Hat Ceph Storage 5 Administration Guide at https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/5/html-single/administration_guide

Discuss Cloud Storage with Red Hat Ceph Storage

Go to community

Red Hat Ceph Storage for OpenStack (CL260)

Haley_Ruccio

3 sie 2023

Build, expand and maintain cloud-scale, clustered storage for your applications with Red Hat Ceph StorageCloud Storage with Red Hat Ceph Storage (CL260) is designed for storage administrators and cloud operators who deploy Red Hat Ceph Storage in a production data center environment or as a component of a Red Hat OpenStack Platform or OpenShift Container Platform infrastructure. Learn how to deploy, manage, and scale a Ceph storage cluster to provide hybrid storage resources, including Amazon S3 and OpenStack Swift-compatible object storage, Ceph-native and iSCSI-based block storage, and shared file storage. This course is based on Red Hat Ceph Storage 5.0.Course summaryDeploy and manage a Red Hat Ceph Storage cluster on commodity servers.Perform common management operations using the web-based management interface.Create, expand, and control access to storage pools provided by the Ceph cluster.Access Red Hat Ceph Storage from clients using object, block, and file-based methods.Analyze and tune Red Hat Ceph Storage performance.Integrate Red Hat OpenStack Platform image, object, block, and file storage with a Red Hat Ceph Storage cluster.Integrate OpenShift Container Platform with a Red Hat Ceph Storage cluster.Target AudienceThis course is intended for storage administrators and cloud operators who want to learn how to deploy and manage Red Hat Ceph Storage on servers in an enterprise data center or within a Red Hat OpenStack Platform or OpenShift Container Platform environment.Developers writing applications that use cloud-based storage will learn the distinctions of various storage types and client access methods.Recommended trainingTake our free assessment to gauge whether this offering is the best fit for your skills.Red Hat Certified System Administrator (RHCSA) certification, or equivalent experience.For candidates that have not earned an RHCSA or equivalent, confirmation of the correct skill set knowledge can be obtained by taking the online skills assessment.Some experience with storage administration is recommended but not required.Technology considerationsThis course does not have any special technical requirements.This course is not intended for BYOD.Internet access is recommended.

Welcome to the Red Hat Ceph Storage for OpenStack (CL260) group in the Red Hat Learning Community!

cschunke

31 lip 2023

We are excited to launch a space dedicated to the Red Hat Training course CL260! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to CL260.Read more about Red Hat Ceph Storage for OpenStack here.

381

Revision: cl260-5.0-29d2128