Ceph for government and defense

Ceph for government and defense: why self-hosted storage fits sovereign and classified-adjacent work

Agencies and defense programs that must keep data under their own control, sometimes with no path to the internet, need storage they can run inside their own boundary. Ceph fits because it is open-source software that a team installs and operates on hardware it controls, so no vendor cloud sits between the data and the operator. The project's source is licensed under LGPL-2.1 or LGPL-3, and the project itself sells no paid edition, so the software cost is the cost of your own staff, hardware and any partner you hire. Ask your legal and procurement teams to confirm how the LGPL terms apply to any modifications you plan to distribute. The software carries no certification of its own. Any accreditation claim belongs to the complete system, including hardware, operations and evidence, and is decided by the independent assessor or authorizing body.

Compared with a commercial cloud bucket, the work moves to your team. The provider no longer designs placement, so your team owns the CRUSH map and failure domains that decide which hosts, racks and sites hold each copy. Your team also owns key custody for any encryption at rest, the cephadm-managed container images and host patching, and the evidence that each control operates. A managed bucket hides those tasks behind a service agreement. In a self-hosted Ceph cluster, they appear on your own runbook, and an auditor will ask who performed them and where the records are kept. Before design starts, confirm which Ceph release your accreditation boundary will support and how you will apply security fixes to it, since the project lists Tentacle and Squid as its actively maintained releases with stated end-of-life dates.

Start the boundary decision early. Write down which datasets, which administrators and which networks fall inside the system, and treat the monitors, Manager, Dashboard and object gateway as components that need controls of their own. Decide which access paths your authorizing official will accept and which federation or certificate sources the Dashboard and gateway will use, then test that design on a non-production cluster. Ceph gives you the building blocks, but the proof that the combined system meets your requirements comes from your own testing and the assessment that follows.

Which government and defense requirements change the Ceph build

This table maps each government and defense requirement to what it asks for, and what it means for encryption, key handling, access and evidence in a Ceph build. Read each row as a question to confirm with your assessor or contracting office before the design is fixed, since the applicable baseline depends on your system categorization and contract terms.

Requirement	What it asks for	Build impact for Ceph
NIST SP 800-53 baselines	SP 800-53B selects 149 controls and enhancements at low, 287 at moderate and 370 at high, drawn from Release 5.2.0 of SP 800-53.	Confirm the impact level of the data first. The baseline sets how many controls the cluster, RGW and admin hosts must evidence, so decide early which RGW, RBD and CephFS services sit inside the boundary.
CJIS Security Policy v6.1 encryption	For criminal justice information in transit and at rest outside physically secure locations, FIPS 140-3 validated modules or FIPS 197 AES with 256-bit keys.	Confirm that the cryptographic modules used for msgr2 secure mode, RGW TLS and any disk or object encryption meet the FIPS requirement, and that AES-256 is configured rather than the 128-bit default in your chosen setup.
CJIS vulnerability scanning	Vulnerability scanning at least monthly, mapped to the RA-5 control.	Schedule scans against cephadm hosts, Dashboard, RGW endpoints and the container images in use. Keep scan reports and remediation tickets as evidence, and plan an offline vulnerability feed for air-gapped sites.
CUI on non-federal systems (32 CFR 2002.14(h)(2))	Agencies use NIST SP 800-171 to set safeguards for CUI on non-federal information systems, unless the CUI category prescribes other safeguards.	If a contractor or partner operates the Ceph cluster, the safeguards it must meet come from the agency requirement. Map access control, audit logging and encryption in transit to those requirements before choosing the deployment site.
CMMC Level 2 cloud restriction (32 CFR 170.17(c)(5))	A cloud service may store or process CUI for a defense contractor only if it is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements.	A self-operated Ceph cluster is not a cloud service the contractor buys, so the restriction usually turns on whether a hosting provider or managed service sits in the path. Confirm with your assessor how the cluster is classified and document the operator, location and access model.
NIS2 scope exclusions	NIS2 covers central government entities and lists public administration as highly critical, but does not apply to entities working in national security, public security, defense or law enforcement.	Determine whether the operator falls in scope or is excluded before you design the evidence pack. Exclusion from NIS2 does not remove the contractual or national controls that still apply to the storage.
ADA Title II web content (WCAG 2.1 A and AA)	State and local government web content and mobile apps, including those provided through contracts, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200).	This applies to user-facing portals and download pages built on RGW or Dashboard front ends, not to the storage protocols themselves. Include accessibility testing of any citizen-facing interface in the delivery scope and keep test results as evidence.

How a self-hosted Ceph cluster fits inside an accredited boundary

A Ceph cluster running on agency-owned hardware is not automatically a FedRAMP cloud service. The FedRAMP scope in OMB memo M-24-15 covers cloud products and services that hold federal information on behalf of an agency, and it treats a system used only for one agency's operations, not offered as a shared service, as out of scope. That means the assessment turns on facts you control: who operates the cluster, whether any other tenant or organization consumes it, what data flows cross the boundary, and which administrators can reach the hosts, the cephadm orchestrator and the Dashboard. Map each of these before you pick a control baseline, and document them so the boundary diagram matches the running system. Confirm the scope determination with your assessor or authorizing official before procurement, because a multi-tenant RGW deployment serving several business units can change the answer.

Within that boundary, msgr2 secure mode is the Ceph setting that protects traffic between daemons and clients. Messenger v2 listens on port 3300, and its secure mode encrypts all post-authentication traffic with AES-GCM and adds integrity checks, per the Ceph messenger v2 documentation. Plan the firewall rules, the ms_cluster_mode and ms_service_mode settings, and the client configuration together, and test that legacy clients either connect securely or are rejected. Ask your assessor which control IDs in your chosen baseline map to transmission protection, and collect evidence from a live cluster, such as configuration exports and captured connection settings, rather than relying on the design document alone.

Encryption in transit does not settle encryption at rest or key custody. Ceph's messenger protects data moving between components, but the team decides how OSD data is encrypted, where dm-crypt keys are generated and stored, who can unlock volumes after a reboot, and how keys are rotated and destroyed when drives leave service. Those responsibilities stay with your team or your contracted operator, and they must be written into the system security plan with named roles. Decide early whether keys live in an external key management system inside the boundary, and confirm with your assessor and the applicable CJIS or CUI requirements which cryptographic module validation (FIPS 140-3 certified or equivalent) you must show for each path.

Choosing a deployment model for connected, isolated and air-gapped sites

A connected site can pull packages and container images directly from upstream registries and repositories during bootstrap and upgrades. That convenience is useful, but many public sector security programs still require that every artifact entering the environment be pinned, scanned and recorded, so direct pulls alone rarely satisfy an assessor. Most teams in this model mirror the sources they need into an internal registry and package repository, then point cephadm at that mirror.

Bootstrap source: cephadm bootstraps the first Monitor and Manager on a host, then adds hosts and services. Confirm which container image reference the bootstrap uses and whether it resolves to your internal registry.
Image pinning: Record the exact image digest for the release you deploy, such as the Tentacle or Squid line described in the Ceph active releases page, rather than a floating tag.
Update path: Upgrades pull new images from the mirror in a planned window, so the mirror itself becomes a controlled change point.
Egress rules: Restrict outbound access from cluster hosts to the mirror and time sources only, and log denied attempts.
Integrity checks: Verify signatures or checksums of mirrored artifacts before promotion. The analogy to NERC CIP-013-2 supply chain verification is illustrative only, since that standard governs electric utilities.

Before you commit to this model, confirm with Ceph documentation and your own change board which image and package sources your cephadm version expects, and whether your accreditation boundary includes the mirror.

Ceph settings and integrations that matter in government environments

Government deployments are judged on who can reach the cluster, who can act inside it and how identity and policy are enforced. The settings below are the ones reviewers usually ask about first, and each one needs a decision recorded before the cluster is built.

cephadm host access and SSH keys

cephadm manages every host through SSH, so whoever holds its key can change the cluster. Decide which administrative accounts may reach the orchestrator, how the cephadm SSH key is generated, stored and rotated, and which hosts are included in the cluster at all. Document the procedure for removing a host from the orchestrator when it is retired or compromised. Confirm with your security team how these keys sit inside your privileged access management process and whether your baseline allows the key to be held on the admin host.

RGW S3 with IAM and STS

The Object Gateway offers S3-compatible and Swift-compatible APIs, along with AWS IAM, STS and SNS-style APIs. For agency tenants, this lets you separate buckets and access by role instead of sharing one set of root credentials. Plan the account and role model before onboarding the first tenant, and decide how temporary credentials are issued and how long they last. Confirm which IAM and STS actions your chosen Ceph release supports, because the set of APIs differs by version and by client tool.

Keystone or LDAP authentication

The Object Gateway can authenticate users against Keystone or LDAP, so object access can follow the directory your agency already uses instead of a separate local user list. Decide which directory is authoritative, how group membership maps to gateway permissions and what happens to access when an account is disabled. Multi-factor authentication is also documented for the gateway, and it should be enabled where your identity policy requires it. Confirm the exact mapping and failure behavior with your identity team before testing begins.

Open Policy Agent for access policy

Ceph's Object Gateway integrates with Open Policy Agent, which lets policy be written and reviewed outside the storage system. This suits environments where access rules must be expressed once and audited across several services. Decide which decisions go to OPA, such as bucket-level or request-level checks, and which stay with native bucket policy. Keep the policy source under version control and test changes against sample requests before deployment. Confirm the supported OPA integration mode with the Ceph release you select.

Dashboard single sign-on

The Ceph Dashboard supports single sign-on through SAML 2.0, and through OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Choose the protocol that your agency identity provider already supports, then confirm how administrator roles are granted from directory groups. Local dashboard accounts should be limited to a documented break-glass procedure. Verify that the dashboard is reachable only from the management network and that session timeouts match your baseline.

CRUSH failure domains and metadata media

CRUSH rules decide where replicas or erasure-coded chunks land, so they define the failure domains your agency can survive, such as host, rack or site. Pair them with a dedicated drive per OSD, enterprise-class SSDs for metadata and bonded network links across two switches, as the hardware recommendations advise. Write the failure domain layout into the design record and test a single-rack or single-host loss before accepting the cluster. Confirm the actual site and rack topology with your facilities team, because the rules cannot protect against a domain that was never modeled.

Rollout phases from requirements to accredited operation

This sequence turns an authorization boundary and control baseline into a Ceph cluster that an assessor can test, with each phase producing evidence for the next. It starts with scope decisions because hardware, release and encryption choices all depend on what the assessor will accept.

Confirm the authorization boundary and baseline
Before any design work, the agency or contractor, its assessor and DeployOpen agree in writing which systems, networks, administrators and data fall inside the boundary, and which control baseline applies (for example, a NIST SP 800-53 baseline selected under SP 800-53B, or the requirements in the CJIS Security Policy or 32 CFR Part 170 if they govern the data). Confirm early whether any cloud or hosted service sits in scope, because that changes the FedRAMP analysis. The step is done when the boundary diagram, data categories and baseline are signed off by the assessor and the owner of the authorization.
Select the Ceph release and support window
Choose between Tentacle (20.2.x) and Squid (19.2.x) based on the release support status on the Ceph releases page, noting the estimated end-of-life dates listed there. Ask the assessor how a release that approaches end of life will be handled in the accreditation package, and whether a planned upgrade must be documented before go-live. The output is a written release decision with the patch cadence, the owner of security fix intake and the date at which the release will be reviewed again.
Design hardware and benchmark before purchase
Size the cluster from the workload and the failure domains the agency needs, following the Ceph hardware recommendations: a dedicated drive per OSD, WAL and DB on shared enterprise SSDs for HDD-based OSDs, bonded network links across two switches, and memory sized for peak rather than average use. Run benchmarks on candidate hardware in a representative lab, since the project advises that no two clusters are alike. The step closes with a bill of materials, benchmark results and a document that maps each failure domain to a physical location, which the assessor will compare against the boundary.
Build the air-gapped mirror and artifact intake
Create the internal repository and container registry that the cluster will pull from, and define how packages and images cross the isolated boundary. Each artifact should be checked for integrity and provenance before it is admitted, with the checks recorded in a transfer log, since supply chain controls such as the NERC CIP-013-2 software integrity requirement show how assessors expect this to be evidenced in other regulated sectors. Confirm with the assessor how the intake process maps to their supply chain and configuration management controls. The step is done when a test artifact passes intake, appears in the internal mirror and the transfer log is reviewed.
Deploy the cluster with cephadm
Bootstrap the cluster with cephadm, which manages Ceph as containers and starts a single-node cluster with one Monitor and one Manager before hosts and services are added. Place monitors and managers across the failure domains defined in the design, and keep the deployment configuration in version control so the build can be reproduced for the assessor. Check cluster health, monitor quorum and OSD placement against the design, then record the configuration. The step is done when the cluster reports healthy status with the planned services running in each failure domain.
Harden the cluster and enable encryption
Apply the hardening decisions from the baseline: restrict cephadm host access, configure client authentication, and enable the msgr2 secure mode so post-authentication traffic is encrypted with AES-GCM and integrity-checked. Set up the Ceph Dashboard single sign-on method your identity provider supports, either SAML 2.0 or OAuth2 through the Management Gateway and OAuth2 Proxy services. Confirm with the cryptography reviewer which FIPS-validated modules and key lengths the baseline requires, because the CJIS Security Policy, for example, sets its own requirements for data at rest and in transit. The step is done when a configuration review confirms each setting against the baseline and the results are saved as evidence.
Collect control evidence and run a restore test
Gather the evidence the assessor will request: configuration exports, access logs, patch records, vulnerability scan results at the frequency the baseline requires, and encryption settings. Run a restore test from the backup target into an isolated environment and measure whether the restored data matches the source, recording the steps and any gaps. Share the evidence index with the assessor before the assessment starts. The step is done when the evidence index is complete, the restore test passes its agreed checks and open findings have owners and remediation notes.
Hand over runbooks and an upgrade calendar
Deliver runbooks for routine operations, incident response, drive replacement, capacity addition and restore, along with a calendar for patch and upgrade reviews tied to the release support dates. Train the operators who will own the cluster, and agree who approves changes and who receives security advisories. Confirm with the assessor how continuous monitoring and change records will be kept after accreditation. The step is done when operators have performed a supervised runbook exercise, the calendar has named owners, and the handover record is signed by the agency or contractor.

Compliance considerations auditors will test

Auditors do not test Ceph itself. They test the controls around it: encryption, access, scanning, boundary and supplier evidence. Each card below names one control area that a government or defense storage deployment has to answer for, and what to check in your own environment. DeployOpen prepares systems, controls and evidence for these assessments, but independent auditors and certification bodies issue the results.

NIST SP 800-53 control mapping

SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects the low, moderate and high baselines that agencies and their assessors use. Map each Ceph component to the control families it supports, such as access control, audit, configuration management and system integrity, and record which party owns each control. A common gap is a control that assumes a single system boundary when the storage cluster, gateways and dashboard sit in separate boundaries. Confirm the baseline with your authorizing official before mapping starts.

CJIS encryption and scanning evidence

For criminal justice information, CJIS Security Policy requires FIPS-validated cryptography or FIPS 197 AES with 256-bit keys for data in transit and at rest outside physically secure locations. Ceph's messenger v2 secure mode encrypts post-authentication traffic, and encryption at rest depends on your OSD and key management design. Keep evidence of module validation, key lengths and vulnerability scans run at least monthly. Ask your assessor which scanner output they accept.

CUI handling under NIST SP 800-171

When a contractor or other non-federal party stores controlled unclassified information on its own systems, NIST SP 800-171 is the baseline agencies set for protecting it. Document where CUI lands in the cluster, which pools and buckets hold it, who administers the cephadm hosts, and how access to the RGW and dashboard is logged. Restrict CUI to named pools and accounts so the boundary can be drawn on a diagram an assessor can follow.

CMMC scope for contractor-run storage

Under the CMMC program, a contractor seeking Level 2 may store CUI in a cloud service only if that service is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. A self-run Ceph cluster is not a cloud service provider, so it is assessed inside the contractor's own scope. That makes every host, administrator and backup copy in scope. Decide early whether a managed or hosted option would change the assessment boundary, and confirm the current CMMC scoping guidance with your certified assessor.

NIS2 applicability by entity type

NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration, and it excludes entities working in national security, public security, defense or law enforcement. Before designing controls, confirm with national counsel whether your entity is in scope and under which category. The answer determines the reporting, supply chain and backup obligations your storage design must evidence.

Accessibility for agency storage portals

If an agency web portal or mobile app fronts stored content, the ADA Title II rule requires it to meet WCAG 2.1 Level A and AA, including content provided through contracts or licenses. Storage itself is not a web page, but a file-download or upload portal built on Ceph RGW is. Ask the agency which entity category it falls under, since the compliance date depends on population served. Test the portal with an accessibility tool and keep the results as evidence.

Questions government and defense teams ask before hiring a Ceph partner

What drives the cost of a Ceph implementation for a government or defense boundary?

The cost is driven by the size of the boundary, the number of sites, the hardware you already own or must buy, and the accreditation evidence the work must produce. Hardware is usually bought by the agency or its integrator, while a partner is paid for planning, deployment, hardening, documentation and handover. The Ceph hardware recommendations advise a dedicated drive per OSD, shared SSDs for WAL and DB on HDD-based OSDs, enterprise-class SSDs for metadata, and bonded network links across two switches, and each of these adds cost. Ask for a written scope that lists the sites, node counts, media, network design, the controls each deliverable supports, and which costs are one-time and which recur, such as support, patching and testing.

How long does a fixed-scope Ceph build take, and what sets the duration?

Duration depends on the number of sites, how many environments must be built (lab, staging and production), how long hardware delivery and physical access take, and how many approval gates sit between design and go-live. A fixed-scope agreement sets the deliverables and timeline in writing before work starts, so ask the partner to tie each milestone to a named artifact such as a validated bootstrap, a tested backup restore or a completed benchmark. The Ceph hardware recommendations advise benchmarking before buying, because no two clusters are alike, and that step often sets the critical path. Do not accept a duration that is not broken down by phase.

What does the agency need to supply before a Ceph partner starts work?

The agency must supply the people, the physical and network environment, and the approvals that the work depends on. In practice this means named staff who can make decisions about the boundary, racks and power, hosts that meet the agreed hardware profile, network segments and addressing, access to the accreditation authority or its delegates, and a process for importing software into the isolated network. Ask the partner to produce a written list of inputs with owners and dates, and to state what happens when an input is late. Clarify early whether the work falls under a contract that requires a specific FedRAMP or CMMC posture, because on-premises systems are assessed within the agency's own scope.

Can an internal team run a Ceph cluster on its own after deployment?

Yes, an internal team can run Ceph alone if it has the skills and time, but the workload is real and should be assessed honestly. cephadm manages a Ceph cluster as containers and was introduced in v15.2.0 (Octopus), so the team must be comfortable with container-based host management, health warnings, drive replacement, capacity additions and upgrades between supported releases. The Ceph releases page lists Tentacle (20.2.x) and Squid (19.2.x) as actively maintained, so the team must plan which release it follows and when it moves. Ask the partner for a handover plan that includes runbooks, training on the operational procedures, and a test of recovery that your own staff perform.

How are software updates verified before they enter an air-gapped Ceph cluster?

Updates are verified by downloading the release artifacts on a connected staging system, checking their integrity and provenance against the publisher's published information, testing them in a non-production cluster, and only then carrying the verified images across the isolated boundary through an approved transfer process. NERC CIP-013-2 is an energy-sector standard, but it describes the principle well: procurement processes should address verification of software integrity and authenticity of vendor software and patches. Ask the partner to document the transfer procedure, the hash or signature checks, who approves each import, and how the release is recorded in change management. Ceph's releases page states that actively maintained releases receive periodic backports and security fixes, so the update cadence should be planned into the operating model.

What does a retainer cover after a Ceph implementation is complete?

A retainer covers the ongoing work that keeps the platform supported after go-live. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so the scope should be written down in the same way as a build. Ask which items are included, such as patch review and application to the test cluster, release upgrades using cephadm, health reviews, backup restore tests, security testing cadence, and response times for incidents. Also ask what is excluded, such as hardware replacement, new sites, or evidence gathering for a specific assessment. Because retainers recur, compare the annual or monthly commitment against the internal staffing cost of doing the same work.

Does a self-hosted Ceph deployment help meet compliance requirements on its own?

No. A self-hosted Ceph deployment can support compliance, but it does not make a system compliant by itself, and no partner can issue an audit report, attestation or certification. Relevant frameworks include NIST SP 800-53 Rev. 5, where SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively, and CJIS Security Policy v6.1, which requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for data outside physically secure locations. A partner can prepare systems, configuration evidence and control mappings for independent assessors to test. Ask for a control matrix that names which controls the implementation addresses and which remain with the agency.

How DeployOpen scopes and delivers Ceph for public sector work

DeployOpen plans, builds, hardens, documents and supports Ceph inside your own infrastructure, including air-gapped networks and data centers you control. Engagements start with a written scope, and the evidence we prepare is organized so your assessors and auditors can test it.

How we scope

Confirm which data classes, such as CUI or criminal justice information, the cluster will hold before any design starts.
Agree the boundary: which sites, networks, admin hosts and clients fall inside the written scope.
Record the authorization path your agency or contractor needs, and which controls the Ceph deployment must support.

How we build

Deploy the cluster with cephadm on hardware you select, with failure domains and network layout set for your sites.
Enable encryption in transit and at rest with key handling agreed with your security team, and test each setting.
Stage offline installation media and verify every package and container image before it crosses the isolated boundary.

How we hand over

Deliver configuration baselines, network diagrams, runbooks and restore procedures written for your operators.
Document control mappings and evidence collection so your auditors can trace each claim to a configuration or log.
Run a recovery test with your team and record the results as part of the handover package.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing alongside the build.
Plan Ceph release upgrades with your change process, staging each step against the release's support window.
Keep patching, vulnerability review and offline update procedures current as your accreditation requirements change.

Ceph for government and defense