CephXXXII · Least Privilege CapabilitiesLeast Privilege Capabilities
Capabilities for monitoring and metrics clients
What you'll learn
- Construct a read-only monitoring capability
- Distinguish mon, mgr, and osd read requirements
- Configure Prometheus and dashboard access safely
- Assess what a compromised monitoring credential exposes
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
Monitoring credentials are widely distributed — every metrics collector,
every dashboard, every alerting integration — and they are frequently
created with client.admin because it was to hand. A read-only credential
takes one command and removes an entire class of exposure.
The minimal grant
ceph auth get-or-create client.monitoring \
mon 'allow r' \
mgr 'allow r' \
-o /etc/ceph/ceph.client.monitoring.keyringThat is sufficient for:
ceph -n client.monitoring --keyring ... -s
ceph -n client.monitoring --keyring ... df
ceph -n client.monitoring --keyring ... osd tree
ceph -n client.monitoring --keyring ... pg stat
ceph -n client.monitoring --keyring ... health detailNo osd capability is needed — cluster status comes from the monitors and
the manager, not from reading objects. A monitoring client that has an
osd capability can read your data.
Where the data comes from
| Metric source | Capability |
|---|---|
| Cluster health, PG states, OSD map | mon allow r |
Manager module output, ceph df detail | mgr allow r |
| Prometheus module metrics endpoint | mgr allow r |
| Per-OSD performance counters | mgr allow r |
| Object contents | osd — not needed |
The Prometheus module
The manager’s Prometheus module exposes an HTTP endpoint that does not use cephx at all:
ceph mgr module enable prometheus
ceph config set mgr mgr/prometheus/server_addr 10.20.0.10
ceph config set mgr mgr/prometheus/server_port 9283Because it is unauthenticated by default, the protection is network-level: bind it to a management interface and restrict access with firewall rules. Treat the endpoint as sensitive — it reveals cluster topology, capacity, and workload patterns.
Dashboard users
The Ceph dashboard has its own user database with roles, separate from cephx:
ceph dashboard ac-user-create viewer -i /path/to/password read-only
ceph dashboard ac-role-show read-onlyUse the read-only role for anyone who does not need to make changes.
This is a third identity database to include in an access audit, alongside
cephx and RGW users.
Quiz
Knowledge check · 4 questions
Q1. Which capability set is sufficient for a Prometheus exporter collecting Ceph cluster metrics?
Q2. The manager's Prometheus module endpoint is protected by cephx authentication.
Q3. Replace an over-privileged monitoring credential.
The metrics collection stack — Prometheus, a Grafana datasource, and two alerting integrations — all use client.admin keyrings distributed to a monitoring host that several teams can log into.
Q4. Why is `mon allow r` a genuine security boundary rather than a convention?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Create a dedicated read-only monitoring entity at cluster build
time so nobody reaches for client.admin later, and audit for
client.admin keyrings on hosts that are not administrative. Restrict the
Prometheus endpoint at the network layer and treat its output as
sensitive — it describes your cluster in detail to anyone who can reach
it.
Cross-course references
- Kubernetes: a read-only ClusterRole for metrics scraping is the direct equivalent
- Linux: monitoring agents running as an unprivileged user follow the same principle