Hardening a Ceph host

Advanced⏱ ~18 mincephsystemctlss

What you'll learn

Identify what a Ceph host exposes
Apply host-level hardening appropriate to Ceph
Handle the container runtime's requirements
Verify the hardening without breaking daemons

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

A Ceph host holds keys, mounts data devices, and runs containers with elevated privileges — so host compromise is cluster compromise.

What a Ceph host exposes

ls -l /etc/ceph/
ls -l /var/lib/ceph/*/

Asset	Consequence if reached
`/etc/ceph/ceph.client.admin.keyring`	full cluster control
Per-daemon keyrings under `/var/lib/ceph/<fsid>/`	that daemon’s identity
The block devices	raw BlueStore data
The cephadm SSH key on the bootstrap host	root on every cluster host
The container runtime socket	container execution as root

# admin keyring permissions
stat -c '%a %U:%G %n' /etc/ceph/ceph.client.admin.keyring 2>/dev/null

It should be 600 root:root, and it should not be on hosts that do not
need cluster administration.

Host-level hardening

Applicable to Ceph hosts:
  minimal package set; no unrelated services
  SSH key-only, no password authentication, no root password login
  a host firewall matching the port inventory
  SELinux or AppArmor enforcing
  auditd recording access to keyring paths
  automatic security updates for the host OS, excluding Ceph packages
  time synchronisation, which Ceph requires anyway

systemctl list-units --type=service --state=running | wc -l
ss -ltnp | grep -v -E 'ceph|radosgw|sshd|node_exporter'

grep -E '^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \
  /etc/ssh/sshd_config

getenforce 2>/dev/null || aa-status --enabled && echo "apparmor enabled"

# audit access to the keyring paths
auditctl -w /etc/ceph/ -p rwa -k ceph-keys
auditctl -w /var/lib/ceph/ -p wa -k ceph-state

The container runtime

cephadm runs daemons as containers with host networking, privileged
access to devices, and bind mounts of the daemon directories.
That is required for the daemons to work.

Constraint	Implication
Containers need device access	OSD containers reach their block devices
Host networking is used	container network policy does not apply
The runtime socket is root-equivalent	restrict access to it as such
Images come from a registry	pin and verify the registry source

ls -l /run/podman/podman.sock 2>/dev/null || ls -l /var/run/docker.sock 2>/dev/null

Anyone who can reach the container runtime socket can start a privileged
container, which is root on the host. It is a root-equivalent interface
and needs root-equivalent permissions.

ceph config get mgr mgr/cephadm/container_image_base

Verifying without breaking daemons

# after each change
ceph -s
ceph orch ps --refresh | grep -v ' running '
systemctl --failed

# SELinux denials, which are the common breakage
ausearch -m avc -ts recent 2>/dev/null | tail -20

Apply changes to one host, verify its daemons for a period, then proceed.
A hardening change that breaks daemons on every host simultaneously is
avoidable.

Quiz

Knowledge check · 4 questions

Q1. Why is the cephadm SSH key broader in consequence than `client.admin`?

The admin keyring grants control of Ceph; the SSH key grants privileged access to every machine Ceph runs on, including the devices and every key stored there The SSH key never expires, while a cephx key carries a rotation deadline the monitors enforce, so its window of usefulness to an attacker is unbounded rather than bounded by a schedule It cannot be rotated without redeploying every daemon, so a leak has to be tolerated until the next maintenance window rather than closed immediately It bypasses cephx entirely, so an attacker holding it reads and writes pool data directly without any capability being checked by the monitors
Q2. Access to the container runtime socket is a limited privilege on a Ceph host.

True False
Q3. Harden a Ceph host without breaking it.

A team plans to apply SELinux enforcing, a host firewall, and SSH restrictions across twelve Ceph hosts.
Q4. Which Ceph host assets grant what if reached?

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

Production discipline

Protect the container runtime socket and the cephadm SSH key as root-equivalent secrets — the socket permits a privileged container, and the SSH key grants administrative access to every host. Apply hardening one host at a time and check ausearch for SELinux denials before proceeding.

Cross-course references

Kubernetes: kubelet and container runtime sockets carry the same root-equivalence
Linux: staged application of hardening prevents fleet-wide breakage