Entities: users and daemons in the cephx namespace

Intermediate⏱ ~15 minceph

What you'll learn

Read and construct cephx entity names
List and inspect entities in a cluster
Distinguish daemon entities from client entities
Create and remove entities safely

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

The entity namespace is the access-control surface of the whole cluster. Every credential that exists is listed in one command, and being able to read that list — and recognise what should not be in it — is the foundation of any Ceph security review.

Naming

Entity names are type.id:

Entity	Meaning
`client.admin`	the bootstrap administrator
`client.rbd-prod`	an application client
`osd.12`	OSD number 12
`mon.ceph-mon-01`	a monitor daemon
`mgr.ceph-mon-01`	a manager daemon
`mds.cephfs-a`	a metadata server
`client.bootstrap-osd`	a deployment credential for creating OSDs

The client. prefix is often omitted on the command line — ceph -n rbd-prod and ceph -n client.rbd-prod mean the same thing.

Listing what exists

ceph auth ls

osd.12
    key: AQBx...
    caps: [mgr] allow profile osd
    caps: [mon] allow profile osd
    caps: [osd] allow *
client.rbd-prod
    key: AQCz...
    caps: [mon] allow r
    caps: [osd] allow rwx pool=rbd-vms

This is the audit surface. Read it periodically and ask of every entry: should this exist, and are its capabilities the minimum that works?

ceph auth get client.rbd-prod
ceph auth print-key client.rbd-prod

Daemon entities

Daemons get their entities at deployment time, usually from cephadm, and they use capability profiles rather than explicit grants:

caps: [mon] allow profile osd
caps: [mgr] allow profile osd

A profile is a named, maintained capability set appropriate to a role. Using profiles rather than hand-written grants for daemons means upgrades that require new permissions do not break the daemon.

Creating and removing

# create with capabilities in one step
ceph auth get-or-create client.backup \
    mon 'allow r' \
    osd 'allow rw pool=backup-data' \
    -o /etc/ceph/ceph.client.backup.keyring

# modify capabilities later
ceph auth caps client.backup \
    mon 'allow r' \
    osd 'allow rw pool=backup-data, allow r pool=backup-index'

# remove
ceph auth del client.backup

ceph auth caps replaces the entire capability set rather than adding to it. Omitting a capability you meant to keep silently removes it — always specify the complete intended set.

Quiz

Knowledge check · 4 questions

Q1. What does `ceph auth caps client.backup osd 'allow rw pool=data'` do to an entity that previously also had a mon capability?

Adds the osd capability and leaves the existing mon capability intact Fails, because a mon capability is required alongside any osd grant Creates a second entity carrying only the new capability set Replaces the entire capability set, removing the mon capability
Q2. Daemon entities typically use capability profiles rather than explicit capability strings.

True False
Q3. Audit the entity list on an inherited cluster.

You take over a cluster built by a contractor three years ago. `ceph auth ls` returns 47 entities, several with names suggesting former staff, test applications, and one called client.temp with `osd allow *`.
Q4. Why does losing every monitor without a backup mean losing every cephx key?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Review ceph auth ls on a schedule and treat every entity without an identified consumer as a finding. Export the auth list before any capability change so a mistake is recoverable, and standardise entity naming so the list is readable by someone who did not create it.

Cross-course references

Kubernetes: ServiceAccount and RBAC audits have the identical shape and the same stale-credential problem
Linux: reviewing /etc/passwd and sudoers for orphaned accounts is the same exercise