Ceph security hardening guide

Ceph security hardening starts with what the cluster exposes

If your team has a self-hosted Ceph cluster or is planning one, you need to show that it protects data in transit, at rest and in administration. Hardening is a set of configuration decisions made at build time, not a single switch you flip after the cluster is running. The first useful step is an inventory of what the cluster exposes, because each exposed surface needs its own controls and its own evidence.

The work is harder than it looks because Ceph has several surfaces, and each one behaves differently. Monitors hold cluster maps and authenticate every daemon and client. OSDs move data between hosts and handle encryption at rest. Managers host modules, including the Dashboard. The Object Gateway (RGW) exposes S3 and Swift APIs to applications. Clients, including RBD, CephFS and RGW users, connect with their own keys. Administrative shells, such as cephadm and the ceph command line, can change the whole cluster. A control that protects one surface does nothing for another.

Your deployment method changes what is reachable. With cephadm, daemons run as containers, and the ports they listen on depend on the host networking and firewall rules you choose. Separate public and cluster networks, bonded links and any load balancer in front of RGW or the Dashboard each change the attack surface. Ask the implementer to write down, for every daemon type, which network it binds to, which ports it opens and which hosts may reach it. That list becomes the basis for firewall rules and for your review of the cluster.

The controls depend on the Ceph release you run. The Ceph releases page lists Tentacle (20.2.x) and Squid (19.2.x) as the actively maintained releases, and it states that these receive periodic backports and security fixes. Setting names, defaults and supported options can differ between releases, so confirm every setting you plan to use against the documentation for your exact release before you change production. Record the release and the version you tested, because an audit will ask which configuration applied to which version.

Start the hardening plan with three questions: which surfaces are reachable from which networks, which identities can administer the cluster, and which data must be protected in transit or at rest. Write the answers as a short table with one row per surface. Each row should name the owner, the control, the release-specific setting, and the test that proves the setting is active. Review the table with your security team before build, and repeat the review after every upgrade, because a release change can alter defaults that the table depends on.

Which Ceph components carry security settings

A Ceph cluster exposes security settings across its messaging, authentication, storage, network, management and object gateway layers. Each surface below controls a different part of the trust boundary, so hardening means reviewing all of them rather than one setting in isolation.

Messenger v2 secure mode

Messenger v2 runs on port 3300 and carries daemon and client traffic. Its secure mode encrypts all traffic after authentication with AES-GCM and adds integrity checks. Confirm that every daemon and client path negotiates msgr2, that secure mode is set where your clients support it, and that no legacy v1 listener is left open on port 6789.

cephx authentication and capabilities

cephx issues keys that identify users, daemons and clients, and capabilities define what each key may do against monitors, OSDs, managers and metadata servers. Review every key with an audit of its caps, remove keys that no longer map to a workload, and confirm that application keys are scoped to the pools or namespaces they need rather than granted cluster-wide access.

OSD data devices and encryption at rest

OSDs store the data, and encryption at rest is configured per OSD device when the cluster is built. Because this choice is difficult to change later on live disks, decide it during design and verify that every OSD on every host was created with encryption enabled. Also confirm how encryption keys are stored and who can retrieve them.

Public and cluster networks

Ceph separates client-facing traffic on the public network from replication and recovery traffic on the cluster network. Check that monitors and OSDs listen only on the networks intended for them, that the cluster network is not reachable from client segments, and that firewall rules match the ports each daemon actually uses. Bonded links across two switches reduce single-point exposure.

Manager Dashboard access

The Dashboard is a web administration surface served by the Manager and is a common target for unauthorized configuration changes. Restrict which networks can reach it, review its user roles, and confirm its TLS configuration. If you plan single sign-on over SAML 2.0 or OAuth2, confirm which cephadm services your version requires for the OAuth2 path before relying on it.

RGW S3 and Swift endpoints

The Ceph Object Gateway exposes S3-compatible and Swift-compatible APIs to applications and users. Check how each endpoint authenticates callers, which identity sources are enabled (such as LDAP, Keystone or STS), how access keys are issued and rotated, and whether bucket policies and user quotas limit what a tenant can read or write. Confirm TLS on every public endpoint.

cephadm as the configuration path

cephadm deploys and configures the cluster as containers, so its settings, service specifications and host access determine much of the security posture. Review who holds SSH access to the orchestrator host, where cluster configuration changes are recorded, and whether container images come from a source you have verified. Confirm that the same review applies if you use Rook on Kubernetes instead.

How msgr2 secure mode protects traffic between daemons and clients

Ceph's messenger v2 protocol, introduced in Nautilus and listening on port 3300, has a secure mode that encrypts all traffic after authentication completes and adds integrity checks to each message using AES-GCM. For a hardening review, the practical question is not whether the feature exists but whether every connection in your cluster actually negotiates it. Monitors, OSDs, Managers, MDS daemons, RGW instances and clients each make connections that can fall back to other modes depending on configuration, so the review should list every connection path and confirm the mode each one uses.

Authentication happens before secure mode applies. The cephx handshake that proves a client or daemon's identity runs earlier in the connection, and secure mode protects what follows. That ordering matters for scope. Secure mode does not replace key hygiene, key scoping or access control on the cluster, which are covered elsewhere on this page. It also does not protect data at rest on OSDs. Treat msgr2 as the protection for the wire between Ceph components and their clients, and plan separate controls for the other layers.

Traffic outside Ceph needs its own treatment. Monitoring agents that scrape Ceph metrics, load balancers in front of the Ceph Object Gateway, and hypervisor connections to RBD volumes or CephFS mounts are separate network paths. Some of them may terminate TLS at a proxy, some may speak protocols that msgr2 does not cover, and some may run on networks that were never part of the Ceph design. List each of these paths, record how it is encrypted and who owns it, and assign a check for each one rather than assuming the Ceph setting covers it.

Before you rely on secure mode, confirm with the Ceph messenger v2 documentation and the release notes for your version how mixed-version clusters behave, how older clients negotiate connection modes, and which modes your configuration allows to be used. Mixed-version periods are common during upgrades, so check what a cluster does when some daemons or clients cannot negotiate secure mode, and whether the setting you choose forces that failure to surface as a refused connection or a silent downgrade. Record the answers for the exact release you run.

Test with the clients you actually run, not a generic test client. Use the kernel RBD and CephFS clients, the librbd and libcephfs builds in your hypervisors and applications, and the S3 clients your teams use against RGW. Capture the connection mode on the wire or in daemon logs for each one, confirm that secure mode is negotiated where you expect, and repeat the test after every upgrade or client update. A clean result on one client version does not establish the result for another.

Which hardening options fit your cluster and what they cost to run

This table compares six Ceph hardening choices, showing when each one fits a cluster and what the team must keep doing once it is live. Read each row as a trade-off: the security gain sits in the middle column, and the recurring work your staff or partner will carry sits in the right column. Most teams should adopt the controls that cost little to run first, then schedule the heavier ones against a known maintenance window.

Option	When it fits	Operational cost
msgr2 secure mode: enforced	Clusters where all clients and daemons run releases that support msgr2 secure mode and the network carries sensitive data across untrusted segments.	Test every client type, including older kernel mounts and third-party tools, before enforcing. Keep a rollback plan and watch for clients that fail to connect after the change.
msgr2 secure mode: allowed	Mixed-version estates or migrations in progress where some clients cannot yet negotiate secure mode.	Lower immediate risk of breakage, but plaintext connections remain possible. Someone must track which clients still connect unencrypted and set a date to enforce.
OSD encryption: set at deployment	New builds where the data classification requires encryption at rest from day one and the key management system is ready before the first OSD is created.	Key handling begins at build: generate, store and back up dropout-safe keys in your key manager, and define who can release them. Rekeying later is harder, so plan key rotation as a documented procedure.
OSD encryption: added later	Existing clusters that now face an encryption requirement and can replace OSDs host by host while keeping enough redundancy.	Each OSD must be drained, rebuilt and re-added, which adds recovery load and change tickets for every host. Plan the work across maintenance windows and verify cluster health between steps.
Single network	Small clusters or lab environments where separate networks add more complexity than the traffic justifies.	Client, replication and recovery traffic compete on one path, so security monitoring and throttling are harder. Review traffic patterns during recovery events to confirm the single path holds.
Separate public and cluster networks, with bonded links across two switches	Production clusters where replication and recovery traffic should be isolated from client access, and where a switch failure must not isolate hosts.	Two networks mean two sets of addressing, firewall rules, VLANs and switch configuration to maintain. Each change needs review on both paths, and bond health must be monitored continuously.
Dashboard reached directly	Small internal deployments on a restricted management segment where administrators connect from known workstations.	Certificate renewal, login policy, and access reviews fall to your team. Exposure is wider, so firewall rules and audit logs need regular review.
Dashboard behind a reverse proxy or restricted network	Environments where administrators reach the cluster through a jump host, VPN or proxy that enforces authentication and logs access.	The proxy becomes another system to patch, certify and monitor. Confirm with your Ceph version whether your SSO option requires the Management Gateway and OAuth2 Proxy services, and test failover of the proxy path.
RGW TLS terminated at the gateway	Deployments where encrypted transport must reach the gateway itself, such as direct client access or strict end-to-end encryption requirements.	Each gateway needs a certificate, a private key and a renewal process. Test client trust chains and cipher support after every renewal, since expired certificates stop all S3 traffic.
RGW TLS terminated at a load balancer	Designs that already use a load balancer for TLS offload, certificate management and centralized policy.	Ceph does not manage the front-end certificate, so the load balancer team owns renewal and cipher policy. Traffic between the balancer and gateways needs its own protection and a documented review.
cephadm-managed hosts	Teams that want containerized deployment, orchestrated upgrades and consistent configuration across hosts with routine change handling.	Upgrades and configuration changes flow through cephadm, so the orchestrator account and its access must be controlled. Keep orchestration credentials under the same review as other administrative access.
Stricter change process on top of cephadm	Regulated environments that require documented approval, peer review and evidence for every configuration change.	Every change needs a ticket, a reviewer and a retained record. This slows routine work, so agree on which changes are standard and which need full approval before the first production change.

Build sequence for a hardened Ceph cluster

This sequence takes an external cephadm cluster from release selection to a documented configuration in which encrypted, authenticated traffic flows only over permitted paths, each client holds only the access it needs, and administrative actions can be traced. Each step ends with a check you can repeat later to confirm the controls still hold.

Fix the release and its end-of-life date
Before anything is deployed, choose the Ceph release and record its estimated end-of-life date in the design document. The Ceph releases page lists Tentacle (20.2.x) with an estimated end of life of June 1, 2027, and Squid (19.2.x) with an estimated end of life of October 31, 2026. Confirm the current status on the releases page, since security fixes arrive through periodic backports only for actively maintained releases. Done means the chosen release, its end-of-life date and the planned upgrade window are written down and approved by the platform owner.
Design network segments and bonded links
The platform team designs separate networks for client and monitor traffic, OSD replication traffic and management access, and bonds each host's links across two switches as the Ceph hardware recommendations advise. Firewall rules must limit which subnets can reach the monitor port 3300 and the Dashboard and RGW ports. Check: from a host outside the permitted client subnet, attempt a connection to a monitor address and confirm it is refused, and confirm each bond reports both member links as active on every host.
Bootstrap the cluster with cephadm
The engineering team bootstraps the first node with cephadm, which creates one Monitor and one Manager in containers, then adds hosts and services. Use the same release on every host and pin container images to the chosen release rather than pulling whatever tag is current at deployment time. Check: run the cluster status command and confirm the health reports OK or lists only warnings the team has reviewed, and confirm every added host appears with the expected labels.
Enable msgr2 secure mode and confirm negotiation
Set the messenger configuration so that connections use msgr2 with secure mode, which encrypts all traffic after authentication with AES-GCM and adds integrity checks. Restart daemons in a rolling order so that the setting takes effect. Check: inspect the monitor addresses and confirm they list the v2 endpoint on port 3300, and open a connection from a client and confirm the active connection mode is secure. Any connection reporting an unencrypted mode is a failure to investigate before continuing.
Plan and apply OSD encryption on the devices
Decide how each OSD device is encrypted at rest, including where the encryption keys are stored and who can recover them, and confirm this with your key management policy before deployment. Apply the encryption during OSD creation so that no plaintext data is written to the devices. Check: list the OSDs and confirm each one reports as encrypted, and confirm that a device removed from a host cannot be mounted without the key material. Record the key custody arrangement in the configuration record.
Create cephx users with scoped capabilities
Create a separate cephx key for each client and service, granting read or write capabilities only on the pools, namespaces and paths that client needs, and avoid sharing the admin key with applications. Check: review the capability list for each key with the auth listing command and confirm that no key holds full access unless it is an administrative key with a named owner. Test one scoped key against a pool it should not reach and confirm the operation is denied.
Restrict Dashboard and RGW endpoints and TLS
Expose the Dashboard and the Object Gateway only on the management and client networks defined earlier, and terminate TLS with certificates issued under your own certificate policy. If single sign-on is required, configure SAML 2.0, or OAuth2 with the Management Gateway and OAuth2 Proxy services when cephadm runs them. Check: connect to the Dashboard and RGW from a non-permitted network and confirm the connection fails, then confirm the presented certificate chain matches your policy from a permitted host.
Lock down administrative access and audit trails
Limit administrative logins to named accounts with individual credentials, remove default or unused Dashboard users, and forward Ceph cluster logs and host access logs to your central log store with retention set by your policy. Check: list the Dashboard and cluster administrators and confirm each maps to a named person, then trigger a test administrative action and confirm it appears in the central log within the expected collection window.
Record the configuration for review
Write a configuration record that captures the release and end-of-life date, network design, msgr2 settings, OSD encryption and key custody, the cephx key inventory with capabilities, endpoint exposure, certificate ownership and logging destinations. Store it under version control and have the security owner review it. Done means each control in the record has a repeatable check listed beside it, so an auditor or engineer can rerun the checks after upgrades. Independent auditors, not DeployOpen, decide whether the controls satisfy any framework.

What drives hardening effort and how to keep it down

This table lists the factors that change how much work Ceph security hardening takes and the levers that keep that work contained. Read each row as a question to answer about your environment before scoping, since the same control costs more on a large, multi-tenant estate than on a small single-team cluster. The main takeaway is that most effort comes from the number of clients, people and access paths, so narrowing those is usually the cheapest hardening step.

Driver	Why it changes effort	How to keep it down
Number of hosts and OSDs	Every host needs consistent msgr2 secure mode, network separation and device encryption settings, and drift grows with node count.	Standardize host builds with cephadm specifications and check configuration against one baseline across all nodes.
Number and variety of clients	Hypervisors, Kubernetes, backup tools and S3 applications each need their own cephx identity, network path and tested settings.	Group clients by workload, issue one scoped key per group and retire clients that no longer need access.
Number of administrators and shell-access tools	Each person or automation with host or admin keyring access widens the audit scope and the set of credentials to rotate.	Limit shell access to a small named group, route routine changes through the orchestrator and log every administrative session.
Existing identity and key management integrations	Dashboard SSO, RGW LDAP or Keystone and external key stores each add configuration, testing and failure modes to maintain.	Integrate only the identity sources you already operate, document one owner per integration and test failover of each.
RGW users and buckets with separate access needs	Distinct tenants, buckets and policies multiply the access rules to design, test and review.	Use tenants and shared policy templates for groups with the same needs and avoid per-bucket exceptions.
Compliance evidence requirements	Assessors ask for configuration baselines, key rotation records and access reviews, and each one must be produced and kept current.	Agree the evidence list before build, generate it from configuration exports and schedule recurring access reviews.
Number of environments (lab, staging, production)	Each environment needs its own keys, network design and test runs, and production changes must be rehearsed elsewhere first.	Keep one hardening configuration as code, promote it through environments unchanged and limit lab copies to non-production data.

How hardening changes by deployment model

In an external cephadm cluster, Ceph daemons run as containers on hosts you manage directly, so most controls sit at the host, network and orchestrator layers. The orchestrator connects to each host over SSH, which makes that SSH trust relationship and the host operating system part of the Ceph security boundary. Keyring distribution and administrative access follow host-level permissions, so host hardening carries more weight here than in the other models.

Host access: Restrict who can reach the cephadm SSH identity, and record which hosts hold admin keyrings.
Network separation: Place the public and cluster networks on separate interfaces, and apply host firewall rules that limit messenger traffic to Ceph hosts and approved clients.
Dashboard and RGW certificates: Issue certificates from your internal certificate authority, and confirm how cephadm stores and rotates them.
Image pulls: Cephadm pulls daemon images from a configured registry during bootstrap and upgrades, so that registry becomes a new trust point.

New risks include a compromised registry, a mutable image tag that changes after you approved it, certificate authority roots that some hosts or clients do not yet trust, and an update channel that depends on outbound access to a public registry unless you have changed it.

Confirm with the Ceph documentation which registry your target release uses by default and how to point it at a controlled one, how the orchestrator SSH key is rotated, whether msgr2 secure mode is enforced in that release, and how image digests are pinned for upgrades.

Access control, key scope and secrets handling for Ceph

Most Ceph compromises start with a credential that was broader than it needed to be, stored where it should not be, or never rotated. The cards below cover the controls that limit what a stolen or misused key can reach, from cephx capabilities and orchestrator permissions to the Dashboard, RGW users and OSD encryption keys. Check each setting against the documentation for the Ceph release you run, because capability syntax and option names change between releases.

Scope cephx capabilities per client

Give each client its own cephx user with only the monitor, OSD and manager capabilities its job requires. Restrict OSD capabilities to named pools or RBD namespaces instead of granting cluster-wide access. Review the output of the auth listing regularly and remove users for retired applications, since an unused key with broad capabilities is a standing risk.

Rotate and revoke cephx keys

Plan a rotation schedule for client keys and a documented revocation path for keys that may be exposed, including who can disable a user and how clients are reconfigured. Test rotation on a non-production cluster first, because a client that loses its key without warning can cause an outage. Confirm the exact auth commands and their effect on running clients in the documentation for your release.

Keep keyrings out of repositories and tickets

Keyrings and admin credentials should live in a secrets manager or a restricted file path on the host, not in configuration repositories, runbooks, chat threads or ticket attachments. Audit existing repositories and wiki pages for pasted keyring content, and treat any exposed key as compromised and rotate it. Decide which automation tools can read which keys before they are deployed.

Limit who can run cephadm and orchestrator

Restrict administrative access to the cephadm command line, the orchestrator and the host accounts that can reach them, since these paths can deploy containers and change service placement across the cluster. Separate day-to-day operators from the few people who hold full administrative capability, and log their sessions. Confirm which administrative roles and host access patterns your release supports.

Scope RGW user keys and policies

Issue RGW users separate access keys per application and per tenant, and grant bucket policies only for the buckets each user needs. Review which users hold administrative capabilities in the Object Gateway, and disable keys that are no longer used. Check the access policy and STS options available in your release before relying on them for cross-tenant or temporary access.

Protect the Dashboard

Require strong authentication for every Dashboard account, avoid shared administrator logins, and restrict which networks can reach the Dashboard port through firewall rules or a dedicated management network. Review the Dashboard's TLS configuration and the Management Gateway options if you use them. Single sign-on is covered on its own page, so this card addresses local account policy and network exposure only.

Handle OSD encryption keys with a custody process

OSD encryption keys must survive host replacement, or encrypted data becomes unrecoverable. Write down where key material is held, who can retrieve it, how it is backed up separately from the cluster, and the steps to restore an OSD after a disk or host failure. Rehearse the recovery steps before you need them, and confirm the key storage behavior for your release in the documentation.

How to test that hardening works and fails safely

A hardening control only counts once a test has shown it refuses what it should refuse. For a Ceph cluster, that means one check per control, run against the live cluster and recorded with the configuration it tested. Start with the wire. Confirm that msgr2 secure mode is negotiated on every connection type in use, including client, OSD-to-OSD, and monitor traffic, by inspecting the connection state on each daemon class rather than trusting the configuration file. Then deliberately attempt a path you have disallowed, such as a legacy connection without secure mode, and confirm the connection is refused and the refusal is logged. A test that never fails is not evidence that the refusal works.

Next, prove encryption at rest for OSDs. Pick one OSD on each device class, read raw blocks from the underlying device, and confirm the content is not readable as plaintext. Then confirm that the data cannot be recovered without the key: keep a copy of the key material in escrow outside the cluster, verify the escrow copy opens the device on a test host, and confirm that a host without the key sees only ciphertext. Confirm the key escrow process itself is documented, because a device encrypted with a key nobody can retrieve is a loss, not a control. Scope tests for cephx are similar. Create a limited client key, attempt reads and writes against pools it should not reach, attempt to alter its capabilities, and confirm each attempt returns an authorization error.

Network and interface tests come next. From each segment that should be unreachable, such as the client or internet-facing segment, attempt connections to the monitor ports, the manager and dashboard ports, and the SSH and administrative ports. Expect every attempt to fail. Repeat the same checks from the management network to confirm the intended administrators still have access. For the Dashboard and the Object Gateway, send unauthenticated requests, requests with a valid user holding no rights, and requests against buckets or pages outside that user's scope. Each should be rejected. Finally, perform one administrative action, such as creating a user or changing a pool setting, and confirm it appears in the audit trail with the acting identity, time, and change. If it does not, the audit control has a gap that the other tests will not reveal.

Failure drills test whether the team can recover without loosening controls. Run them on a non-production copy or during a planned window. For a lost or rotated cephx key, confirm the procedure issues a replacement with the narrowest capability set, updates only the clients that need it, and removes the old key so it no longer authenticates. For a failed node, remove it from service, confirm the cluster returns to a healthy state through its normal recovery path, and confirm that the replacement host receives encryption keys and certificates through the approved route rather than copied configuration. For a certificate expiry, confirm the monitoring alert fires before expiry, and rehearse renewal for the Dashboard and Object Gateway endpoints.

The restore rule is the same in each drill: no step may disable secure mode, widen a capability, open a port, or turn off audit logging to get service back. Write that rule into the runbook and make the on-call engineer confirm it before acting. Record each drill's result, the time to restore, and any step that needed an exception. Ask any implementation partner to show how drill results and rollback steps are documented, and confirm with your own compliance lead which evidence your assessor will expect.

What to monitor, back up, upgrade and document after hardening

Hardening settings drift as clusters change, keys rotate and releases age out. The checks below keep the controls from the earlier sections visible, recoverable and provable over time.

Cluster health and transport checks

Watch overall Ceph health status, but also confirm that msgr2 secure mode is still in effect on the connections you intended and that Dashboard and RGW certificates have not reached expiry. A cluster can report HEALTH_OK while a daemon has fallen back to a weaker connection setting or serves a certificate close to lapsing. Build these as scheduled checks with alerts, not as one-off reviews during hardening.

Unexpected authentication failures

Track cephx authentication failures and failed logins to the Dashboard and RGW. Repeated failures from one host may indicate a daemon with a stale or copied key, a misconfigured client or an attempted intrusion. Set a baseline for normal failure volume during the first weeks after hardening, then alert on deviations and record how each alert was resolved.

New keys and capability changes

Review every newly created cephx key and every change to an existing key's capabilities. Scope creep usually arrives as a convenience grant, such as a client given broader pool or administrative rights for a single job. Compare the current key list against an approved inventory at a set cadence and require a ticket for each new key that names its owner, purpose and minimum capabilities.

Custody of cephx and OSD encryption keys

Decide where cephx keyrings, OSD encryption keys and the cluster configuration are backed up, who can retrieve them and how restores are tested. Losing an OSD encryption key can make encrypted data unreadable, while a copy kept beside the cluster can expose it to the same compromise. Record the custodians, the storage location, the retrieval approval path and a restore test for each.

Administrative access audit cadence

Review audit logs for administrative actions on the cluster, Dashboard and orchestrator, including who ran configuration changes, key operations and daemon restarts. Agree on a review frequency with the owning team and a named reviewer, and keep the reviews as dated records. Confirm with your Ceph version which events are logged and how long logs are retained in your environment before you rely on them.

Upgrade planning and control re-verification

Squid's estimated end of life is October 31, 2026, and Tentacle's estimated end of life is June 1, 2027, according to the Ceph releases page. Plan each upgrade as a point where hardening settings, cipher and TLS choices, Dashboard SSO and RGW authentication are checked again on the target release. Upgrade mechanics belong to the Ceph upgrades and support topic.

Documentation an auditor or reviewer will request

Keep a current set covering the architecture and network zones, the configuration baseline, the cephx key inventory, key custody records, the access review log, the change record for each control and the upgrade re-verification results. Store it with version dates so a reviewer can see what was true at any point. DeployOpen prepares this evidence, but independent auditors and certification bodies decide whether it meets a given requirement.

Ceph security hardening questions buyers ask before hiring help

What drives the cost of Ceph security hardening work?

The main drivers are cluster size, the number of clients and services that authenticate to it, how keys and certificates are managed today, and what evidence your assessors will expect. A cluster with a few hosts and one Dashboard is a smaller scope than a multi-site deployment with RGW exposed to several tenants and an external key management system. Cost has two parts: the people doing the review and changes, and the test and change-window effort that follows. Ask for a quote built from a written scope that lists hosts, clients, services, environments (lab, staging, production) and the evidence you need. Most engagements are fixed-scope, so the quote should state deliverables and assumptions before work starts.

How long does Ceph security hardening take to complete?

The timeline depends on the written scope. The main variables are the number of hosts and services in scope, how many environments must be changed and tested, how quickly your team can schedule change windows, and whether encryption at rest or msgr2 enforcement requires a rebuild or rolling restart. Hardening that only tightens cephx capabilities and Dashboard access moves faster than work that touches OSD encryption across a large cluster. We do not state a fixed duration here. Ask for a timeline in the quote that separates assessment, changes, testing and handover, and that names the dependencies on your side.

What does the client need to provide before hardening starts?

Plan to provide a current network diagram showing public and cluster networks, the list of hosts and their roles, and access to those hosts through an approved path. You also need change windows that allow restarts and rolling changes, and named owners for keys, certificates and identity integrations. Owners decide who can rotate cephx keys, who holds certificate material and who approves changes to Dashboard and RGW access. Without these owners, findings often stall at the decision point. Confirm with your change board how emergency changes are handled during the engagement.

Can our internal team harden Ceph without outside help?

Yes. An internal team can do this with the documentation for the Ceph release you run and a written test plan. Start from the official docs for your release, including the cephadm and msgr2 pages, and confirm each setting against your version before changing production. The test plan should cover a staging cluster, rollback steps, client compatibility checks and a checklist for Dashboard, RGW and administrative access. Outside help mainly adds speed, a second review of the design and preparation of evidence for assessments.

What can enabling msgr2 secure mode break?

Enabling msgr2 secure mode can break clients, daemons or tooling that still connect with older protocol settings or that do not negotiate the secure mode. Typical problems include legacy clients on older releases, monitoring or automation that hardcodes the v1 port 6789 instead of 3300, and firewall rules that only allow the old ports. Some mixed-version periods need careful ordering during upgrades. Test every client type in staging, check connections on port 3300 before enforcement, and keep a documented rollback. Confirm the exact settings and compatibility rules in the msgr2 documentation for your release.

What does a Ceph hardening review not prove?

A hardening review examines configuration, design and access at the time of review. It does not prove that the cluster is free of vulnerabilities, that it will stay configured the same way after the next change, or that every workload is protected. It also does not replace penetration testing or continuous monitoring. DeployOpen prepares controls, configuration evidence and documentation for compliance assessments, but we do not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which evidence they accept.

Do we need hardening if our Ceph cluster sits on a private network?

Private networks reduce exposure but do not remove the need for hardening. Internal users, compromised hosts, misconfigured clients and third-party integrations still reach the cluster. Hardening focuses on what can reach each service, which identities hold which cephx capabilities, whether traffic between daemons is encrypted, and how administrative access is logged and reviewed. Confirm your threat model and network boundaries in the first review, because they decide which controls matter most for your environment.

How DeployOpen scopes, builds and hands over Ceph hardening

DeployOpen treats Ceph security hardening as a written, fixed-scope engagement inside your own infrastructure. We agree which controls change, how each one is verified, and what your team receives before any configuration changes begin.

How we scope

Inventory of cluster releases, daemons, hosts, networks and who holds administrative access today
Decisions on msgr2 secure mode, OSD encryption at rest, cephx key scope and network separation
Written decision on whether Dashboard and RGW are exposed, and on any SSO method to be configured
Agreed test plan, change windows and rollback criteria, confirmed before work starts in writing

How we build

Apply changes in a staging cluster first, then roll them to production one daemon group at a time
Set msgr2 secure mode and confirm client compatibility before enforcing it across the cluster
Scope cephx capabilities to least privilege per client and record each key's purpose and owner
Test Dashboard and RGW exposure from outside the management and client networks to confirm access rules

How we hand over

Hardening runbook covering each control, its configuration, and how to verify it after changes
Access review record listing administrative accounts, roles, and the audit log settings in place
Verification results from the agreed test plan, including any items deferred or accepted by your team
Operations notes for key rotation, adding OSD hosts, and checks to repeat after each Ceph upgrade

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Re-check hardening settings when moving between Ceph releases, including the planned move from Squid to Tentacle
Periodic access reviews and configuration drift checks scoped in the retainer agreement
Ask your quote to state what recurs, response expectations, and which items remain your team's responsibility