Keyrings: format, locations, and handling

Why this matters in production

A keyring is a plaintext secret in a file. Everything about how it is created, stored, copied, and deleted is a security decision, and the defaults are convenient rather than careful.

The format

[client.rbd-prod]
	key = AQCzX2VhVjNwMhAAqR7v8NkTzY3pQxLmW9dAfg==
	caps mon = "allow r"
	caps osd = "allow rwx pool=rbd-vms"

Plain INI text. The key is the shared secret; anything holding this file can authenticate as that entity. The caps lines are informational in the file — the authoritative capabilities live in the monitor store.

Where Ceph looks

In order, by default:

/etc/ceph/$cluster.$name.keyring
/etc/ceph/$cluster.keyring
/etc/ceph/keyring
/etc/ceph/keyring.bin

So client.rbd-prod on cluster ceph is found at /etc/ceph/ceph.client.rbd-prod.keyring. Override explicitly when needed:

ceph -n client.rbd-prod --keyring /path/to/keyring -s
ceph config set global keyring /custom/path/keyring

Permissions

chown ceph:ceph /etc/ceph/ceph.client.rbd-prod.keyring
chmod 600      /etc/ceph/ceph.client.rbd-prod.keyring

600 and owned by the account that needs it. A world-readable keyring is a credential handed to every user on the host. Check across your fleet:

find /etc/ceph -name '*.keyring' -perm /o+r -ls

Creating and extracting

# create the entity and write its keyring in one step
ceph auth get-or-create client.backup \
    mon 'allow r' osd 'allow rw pool=backup' \
    -o /etc/ceph/ceph.client.backup.keyring

# extract an existing entity's keyring
ceph auth get client.backup -o /tmp/backup.keyring

# just the key, for embedding in a secret store
ceph auth print-key client.backup

print-key is the right form when feeding a secret manager or a Kubernetes Secret — it emits the key alone with no surrounding file structure.

Distribution

The insecure habits are copying keyrings with scp into shared directories, checking them into configuration management in plaintext, and leaving them in /tmp. The better patterns:

• Generate on the monitor and transfer over an encrypted channel directly to the destination path
• Store in a secret manager and render at deploy time
• For Kubernetes, a Secret populated from print-key
• Never in a Git repository, encrypted or otherwise, unless the repository is itself a managed secret store

Quiz

Production discipline

Audit keyring file permissions across the fleet on a schedule, and make secret-manager storage the default distribution mechanism rather than file copying. Treat any key that has appeared in chat, a ticket, a terminal recording, or shell history as compromised and rotate it — without exception, because the exceptions are how leaks persist.

Cross-course references

• Kubernetes: Secrets carry the same handling requirements and the same paste-into-chat risk
• Linux: SSH private key handling follows identical rules for identical reasons