Manager modules as an attack surface

Advanced⏱ ~17 minceph

What you'll learn

Assess what each enabled module exposes
Identify modules reaching external systems
Decide what should be enabled
Constrain the modules that remain

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

Modules run inside the manager with full cluster access, and each one added is code with that access reachable through whatever interface it opens.

What is enabled

ceph mgr module ls --format json | python3 -c '
import sys,json
d = json.load(sys.stdin)
print("enabled:")
for m in sorted(d.get("enabled_modules", [])): print("  ", m)
print("disabled but available:")
for m in sorted(x["name"] if isinstance(x, dict) else x
                for x in d.get("disabled_modules", []))[:20]: print("  ", m)'

ceph mgr services

The services list is the set of network-reachable endpoints modules have
opened. Anything listed is a surface.

What each class exposes

Module class	Exposure
`dashboard`	an authenticated web UI with full-control roles
`prometheus`	an unauthenticated metrics endpoint
`restful` / API	authenticated programmatic control
`cephadm`	SSH access to every host, the key in the config store
`rbd_support`, `pg_autoscaler`, `balancer`	no network exposure; internal action only
`telemetry`	outbound reporting to an external endpoint
Cloud and external integrations	outbound credentials to third-party systems

ceph telemetry status
ceph telemetry show | head -30

Telemetry is opt-in and its contents are inspectable before enabling.
Reviewing what it sends before enabling it is a reasonable position for
any cluster with a data classification policy.

Deciding what to enable

For each module, ask:
  does anything depend on it?
  does it open a network endpoint?
  does it reach an external system?
  what happens if it fails?
  who maintains it?

Answer	Implication
Nothing depends on it	disable it
Opens an endpoint	it needs the endpoint controls
Reaches externally	it needs an outbound policy decision
Its failure destabilises the manager	it needs to be watched
Third-party module	it is code with cluster access from outside the project

MODULE=dashboard
ceph mgr module disable ${MODULE}
ceph mgr module ls --format json | python3 -c '
import sys,json; print(json.load(sys.stdin)["enabled_modules"])'

Constraining what remains

# bind addresses for modules that listen
ceph config set mgr mgr/dashboard/server_addr 10.10.5.11
ceph config set mgr mgr/prometheus/server_addr 10.10.5.11

# review module configuration for stored credentials
ceph config-key ls | grep -i 'mgr/' | head -20

Module configuration lives in the config-key store, which means module
credentials — cloud API keys, SMTP passwords, webhook URLs — are readable
by anyone with client.admin.

# module and key name taken from the `ceph config-key ls` output above:
MODULE=dashboard
CONFIG_KEY=GRAFANA_API_PASSWORD

ceph config-key get "mgr/$MODULE/$CONFIG_KEY" 2>/dev/null | head -1

Quiz

Knowledge check · 4 questions

Q1. Why does "who maintains this module" matter as much as what it exposes?

An unmaintained module stops receiving updates, so it eventually fails to load against a newer manager and takes the dashboard down with it during an upgrade Unmaintained modules crash more often, and each module crash restarts the whole manager process, so the manager failover rate is what the maintenance question is really asking about rather than the access It determines who can be asked for a fix, which decides whether an incident involving that module can be resolved while it is happening or only afterwards Modules run in the manager process with its broad cephx identity, so they can read state and issue commands regardless of declared purpose — enabling one grants cluster-level access to that code
Q2. Enabling a manager module that holds a cloud API key extends the consequence of an admin keyring compromise beyond Ceph.

True False
Q3. Review the enabled module set.

A cluster has nine modules enabled including one third-party integration that stores a cloud API key, and telemetry which was enabled at bootstrap.
Q4. Which enabled modules open no network endpoint?

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

Production discipline

Treat each enabled module as code running with the manager’s broad cluster capability, not merely as the endpoint it opens. Check which modules store third-party credentials in the config-key store — those extend an admin keyring compromise beyond the Ceph cluster.

Cross-course references

Kubernetes: admission webhooks and operators carry cluster-level access the same way
Linux: a plugin inside a privileged process is not sandboxed from that process