Capabilities: what an entity is permitted to do

Why this matters in production

Capabilities are where least privilege is actually implemented in Ceph. The syntax is compact and unforgiving, and a capability that is slightly too broad is invisible until it is exploited or audited.

The structure

One capability string per subsystem:

ceph auth get-or-create client.example \
    mon 'allow r' \
    osd 'allow rwx pool=app-data' \
    mds 'allow rw' \
    mgr 'allow r'

An entity with no capability for a subsystem cannot use it at all. A client that only needs RBD needs no mds capability.

Enforcement location

Each daemon enforces its own capability. The monitor checks mon caps, each OSD checks osd caps on every operation, the MDS checks mds caps. There is no central policy engine — which is why capabilities take effect immediately without any propagation delay, and why an OSD offline during a capability change still applies the new rules when it returns.

Profiles

ceph auth get-or-create client.rbd-user \
    mon 'profile rbd' \
    osd 'profile rbd pool=rbd-vms'

Profiles are named capability sets maintained by Ceph for common roles:

Prefer profiles for standard roles. They are maintained across upgrades, so a release that requires an additional permission for RBD clients does not break entities using profile rbd, whereas hand-written capabilities would need updating.

Verifying

ceph auth get client.example

# test what the entity can actually do
ceph -n client.example --keyring /etc/ceph/ceph.client.example.keyring -s
rados -n client.example --keyring ... -p other-pool ls    # should fail

Testing the negative case matters. Confirming an entity can do its job proves nothing about whether it can also do things it should not.

Quiz

Production discipline

Include negative tests in every capability review — the positive test is what everyone runs and it validates nothing about the boundary. Prefer maintained profiles for standard roles so upgrades do not silently break hand-tuned capability sets, and record the tested boundaries alongside the entity definition.

Cross-course references

• Kubernetes: RBAC Role verification needs the same negative testing to be meaningful
• Linux: verifying that a service account cannot read what it should not is the same discipline