Ceph RGW encryption with Vault, KMIP or Barbican

Ceph RGW server-side encryption: when your team needs its own key manager

Server-side encryption on RGW encrypts object data before it is written to the OSDs, so the bytes at rest are never stored in plaintext. A key management service becomes necessary when your organization must hold custody of the keys that decrypt its data, or must produce an audit trail of key use that the storage team cannot alter. The S3 model offers three modes. With SSE-S3, the gateway manages the keys itself. With SSE-KMS, each object is encrypted with a data key that an external key service protects. With SSE-C, the client supplies the key on each request and the gateway does not keep it. Key custody and audit are the usual reasons to move beyond SSE-S3.

Before you design anything, confirm the exact options in the Ceph Object Gateway documentation for the release you will run. The maintained releases are Squid (19.2.x, estimated end of life October 31, 2026) and Tentacle (20.2.x, estimated end of life June 1, 2027), so check the Ceph releases page for current dates and plan around the release that will still be supported for the life of the data. Confirm which key backends the release supports for Vault, KMIP and Barbican, how each backend authenticates to the gateway, and which configuration keys hold the endpoint, token or certificate paths. Ask how the gateway behaves for in-flight requests when the key service is unreachable.

Key custody decisions carry operational risk. Settle who owns the key service, who may read or revoke keys, and how key rotation is scheduled before the first object is uploaded. Back up the key service on its own schedule and test a restore, because losing the key service can make encrypted objects unreadable. Confirm what the key service logs, where those logs are kept and whether auditors can reach them without access to the storage cluster. Finally, check whether your applications send SSE-C headers, since those requests depend on the client holding the key and cannot be recovered by the storage team.

SSE-S3, SSE-KMS and SSE-C compared for RGW

This table compares the three RGW server-side encryption modes by who holds the keys, what an attacker with gateway access could read, what each request must carry and how much operational work each mode adds. Read it as a decision aid: the further a mode moves key handling toward the client, the more the client must do to recover lost keys. Behaviors that depend on specific RGW releases are marked for confirmation in the Object Gateway documentation.

Factor	SSE-S3 (gateway-managed keys)	SSE-KMS (external key manager)	SSE-C (customer-provided keys)
Who creates and stores keys	RGW creates and stores data keys under its own key management	An external key manager such as Vault, KMIP or Barbican holds the key encryption keys	The client creates each key and sends it with every request; RGW does not store it
Can the gateway operator read objects	Yes, the gateway can decrypt objects it serves	Gateway access alone is not enough if the KMS denies the key request; confirm the exact KMS calls in the Object Gateway documentation	No key is stored on the gateway, but a compromised gateway could still see keys sent in requests in transit unless TLS is enforced
What clients must send	Standard S3 request with the encryption header; no key material	Standard S3 request plus the key ID or reference that RGW resolves through the KMS	Three headers per request: the algorithm, the key and the key MD5, on every read and write
Lost key recovery	Handled by the cluster; restore from backup of the key store	Recovered through the KMS backup and its own recovery process	Not recoverable by RGW or DeployOpen; objects encrypted with a lost key are unreadable
Operational burden	Lowest; keys are managed inside the Ceph deployment	Highest; requires running and backing up a key manager, network paths and access policies	Moderate; the application team owns key generation, storage, rotation and distribution
Multisite considerations	Confirm how keys replicate to secondary zones in your release	Confirm whether each zone can reach the KMS and how key IDs map across zones	Client keys must be available to every zone that serves the object; confirm behavior during failover
Blocking or restricting SSE-C	Not applicable	Not applicable	Confirm the RGW option that rejects SSE-C requests before enabling it for a bucket policy or site-wide
When it fits	Protection against media loss and casual exposure, with minimal change for applications	Central key control, rotation and audit requirements that the key manager can evidence	Applications that must hold keys themselves and accept the recovery risk in exchange

Choosing Vault, OpenBao, KMIP or Barbican as the key backend

HashiCorp Vault is the key manager most organizations already know, so it is often the first candidate for SSE-KMS. Licensing changed in a way that matters for procurement. HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE file names IBM as licensor for Vault 1.15.0 or later. That license bars competitive hosted or embedded offerings and converts each version to MPL-2.0 four years after publication. The current release line is Vault 2.2.0, released October 15, 2026.

Edition choice: Vault Community Edition, Vault Enterprise self-managed and HCP Vault Dedicated run the same binary family, but the Enterprise features need a license applied to the cluster.
Enterprise-only features: HSM support and the PKCS#11 provider, along with performance replication, namespaces and FIPS compliance, are listed as Enterprise features, so confirm whether your design depends on them.
Pricing model: Vault Enterprise prices are not published, and self-managed Enterprise buyers are directed to sales, so the cost comes from a written quote.
Storage backend: Integrated storage (Raft) and Consul are the officially supported backends, which affects your high availability design.
Ongoing terms: Review the license terms with counsel, since the BSL restrictions apply to how you offer the product to others.

Confirm with HashiCorp or IBM which edition, license terms and Enterprise features your RGW encryption design requires, and whether your RGW release supports the Vault integration you intend to use.

Why HTTPS behind proxies and cipher mode must be checked first

Key-manager traffic and client requests are only as protected as the path they cross, so confirm this before choosing a key backend. Find out where TLS terminates: at the RGW daemon itself, at the cephadm ingress layer, or at an external load balancer or reverse proxy. If TLS ends at a proxy, the gateway may see plain HTTP and the original scheme may be lost unless the proxy forwards it in a header that RGW is configured to trust. Check that the forwarded scheme reaches RGW correctly, because a misread scheme can cause redirects or signature failures that look like encryption faults. Then confirm the trust chain on both sides: RGW must trust the certificate presented by Vault, OpenBao or the KMIP server, and the key manager must trust the RGW client identity. Record which certificate authority issues each leg and who rotates it.

Next, confirm the cipher mode. In general terms, AES-GCM and AES-CBC are both block-cipher modes, but GCM is authenticated encryption: it produces an integrity tag, so tampered ciphertext is rejected. CBC provides confidentiality without built-in integrity and must be paired with a separate mechanism, so reviewers usually ask whether authenticated encryption is in use. Do not assume which mode a given RGW release uses for server-side encryption. Confirm the configuration key or setting that selects the mode in the release documentation for your exact Ceph version, and test it against an object you can decrypt with the key manager. Keep this separate from messenger v2. Ceph's msgr2 secure mode encrypts traffic between Ceph daemons with AES-GCM after authentication. It protects data in transit inside the cluster, but it does not encrypt objects at rest, so it cannot stand in for object encryption in your evidence pack.

Security considerations for key custody and audit

Server-side encryption moves the security of your data onto the key manager. The cards below cover the decisions that determine whether that trade holds up under review: who can read keys, how client credentials expire, what rotation does to stored objects, how the key manager itself is recovered, and how both systems are logged. Each one should be settled in writing before the first production bucket is encrypted.

Who can read keys

Map every identity that can fetch a data key from the key manager, including the RGW client, human operators, backup jobs and any administrator with access to the storage backend. Confirm that the RGW client can read only the key paths or transit keys it needs, and that no shared administrative token is used for daily gateway traffic. Ask your team to show the policy or ACL that grants each read, not a summary of it. Keep this map current when RGW daemons move between hosts.

Client token and certificate lifecycle

Decide how the RGW client authenticates to Vault, OpenBao or the KMIP server, and how that credential is issued, renewed and revoked. Token time-to-live, certificate validity and the procedure for rotating them after a host compromise should be written down and tested on a non-production cluster. Confirm how a daemon restart behaves when its credential has expired, because a silent failure can block reads of encrypted objects. Record who approves a revocation and how quickly RGW picks up the change.

Key rotation and existing objects

Rotating a key in the manager does not automatically re-encrypt objects already written under the older key. Confirm with the vendor and your own tests which key version an existing object needs to remain readable, how long old versions must be retained, and whether re-encryption is a planned job with its own runbook. Document what happens to multipart uploads in progress during a rotation. Losing an old key version makes the affected objects unrecoverable, so retention of prior versions is a control in its own right.

Backup and recovery of the key manager

The key manager is a stateful service, and its backups are as sensitive as the keys they hold. For OpenBao or Vault with integrated storage (Raft), plan snapshots, their encryption at rest and the unseal or recovery material held separately from them. For PostgreSQL storage, the database backup and its retention rules carry the same weight. Run a restore into an isolated environment and confirm that the RGW gateway can read a test object afterward. Record the recovery time you have actually demonstrated, not the one you hope for.

Audit logging on both systems

Enable audit devices on the key manager and RGW access logging, then confirm that both record the key requests that correspond to object reads and writes. Decide where logs are shipped, who can read them, and how long they are kept. Check that a single bucket and object can be traced from the S3 request through to the key fetch, so an investigator does not have to reconcile timestamps by hand. Ask whether any log field could expose key material or plaintext, and redact it if so.

Separation of storage and key administrators

Storage administrators who manage Ceph pools, OSDs and RGW daemons should not also hold the authority to create, export or change keys in the key manager. Assign key policy to a separate team, with its own approval path for changes to key paths, mounts or auth methods. Test this separation by attempting the actions from each role and recording the results. Where one person must hold both roles during an emergency, define the break-glass procedure and log its use.

How to set up SSE-KMS on Ceph RGW step by step

This sequence takes a non-production Ceph RGW endpoint from release confirmation to tested server-side encryption with a key manager you operate. Each step ends with a check that shows encryption works, unauthorized access is refused, and recovery is documented before any production bucket is changed.

Confirm the Ceph release and encryption documentation
Record the Ceph release your cluster runs and compare it with the Ceph releases page, which lists Squid (19.2.x) and Tentacle (20.2.x) as actively maintained. Read the Object Gateway encryption section for that exact release, because supported key manager backends and option names can differ between versions. Confirm any gap with the vendor or in a test cluster. The step is done when the release, the documented backends and the open questions are written into the change record and signed off by the storage owner.
Deploy the key manager in a highly available layout
Choose the key manager your release supports and your policy allows, such as HashiCorp Vault or the OpenBao fork, and deploy it on at least three nodes using a storage backend the vendor supports for high availability. For Vault, integrated storage (Raft) is the recommended backend for most use cases. Confirm license terms before choosing a product, since Vault releases from 1.15.0 use the Business Source License 1.1. The step is done when a leader election completes and a forced failover of the active node leaves the service reachable.
Create keys and scoped access policies
Enable the secrets or transit capability that your RGW release expects, then create the encryption keys or key paths that will protect buckets or tenants. Write a policy that lets only the RGW identity read and use these keys and nothing else, and use an authentication method suited to servers, such as AppRole for OpenBao. Keep key naming consistent so audit logs can tie each key to an owner. The step is done when a test credential issued to RGW can perform the encrypt and decrypt operations, and the same credential is refused on an unrelated path.
Configure RGW with the key manager endpoint
Set the key manager backend, endpoint and credentials in the RGW configuration using the option names from the documentation for your release. Store credentials in a secret mechanism your cephadm deployment supports instead of plain configuration files, and limit who can read them. Apply the change through the cephadm configuration path and watch each RGW daemon restart. The step is done when every RGW daemon reports healthy after restart and the logs show a successful connection to the key manager without credential errors.
Place TLS in front of RGW and the key manager
Serve RGW and the key manager over HTTPS with certificates whose names match the endpoints clients use. Encryption with customer-provided keys sends key material in request headers, so plain HTTP is not an option for that path. If a load balancer or proxy terminates TLS, confirm it forwards the encryption headers unchanged and that the RGW side also trusts the key manager certificate. The step is done when a client handshake shows a valid certificate chain and a test request through the proxy carries the encryption headers to RGW intact.
Test uploads and downloads in a non-production bucket
Create a bucket in a test tenant, upload objects of several sizes with the server-side encryption request your application uses, and download them with an authorized client. Compare checksums of the downloaded data with the originals, and repeat the test with multipart uploads if your workload uses them. Record which request headers the client must send for each mode. The step is done when every round trip returns identical data and the object metadata shows the expected encryption mode.
Verify ciphertext and failure behavior
Inspect the stored data for a test object in the underlying pool, using the low-level tools available in your lab, and confirm that known plaintext strings are not present. Then send a GET without the required credentials and confirm it is refused. Stop the key manager, attempt a new upload and a download of an encrypted object, and record the exact errors returned. The step is done when the object is confirmed unreadable at rest, unauthorized requests fail, and the outage behavior matches what your runbook expects.
Document rotation and recovery procedures
Write the procedures for rotating keys, replacing the RGW credential, backing up the key manager storage and handling unseal or recovery material for the chosen product. Assign an owner for each procedure and state who may approve a key deletion. Rehearse a restore in an isolated environment and confirm that a backed-up key still decrypts a test object. The step is done when the restore rehearsal succeeds and the signed runbook is stored with the change record for audit.

Blocking SSE-C and keeping multisite zones consistent

Some organizations block SSE-C at the gateway or through bucket policy because the client holds the key. If a client loses that key, the objects cannot be recovered, and the platform team cannot escrow or rotate it on the client's behalf. Auditors also find key custody harder to evidence when the storage team never handles the key material. Confirm before you write the control whether the RGW release in use can refuse SSE-C requests at the gateway, or whether you must enforce the rule through a bucket policy that clients are expected to honor. Test either approach with a request that carries SSE-C headers, and keep the rejected response as control evidence. Do not assume a policy on one bucket covers buckets created later.

In multisite, encryption must agree across zones. The primary and secondary zones need the same encryption settings, the same key manager endpoints, and access to the same keys. If the secondary zone points at a different Vault or KMIP service, or lacks a key that was rotated and never copied, replicated objects can copy successfully yet fail to decrypt after a failover. Build a check that reads a replicated encrypted object from the secondary zone, and run it while the primary is unavailable, since that is the failure you need to survive. Ask the vendor how key manager configuration is kept in step between zones, and whether each zone is configured separately by hand. The Ceph Object Gateway documentation is the starting point for the settings your release supports.

Confirm how replicated encrypted objects behave in the secondary zone for your release. Check whether the object keeps the same key reference, whether it is re-encrypted at the destination, and what happens to SSE-C objects, which need the client's key on every read. Record the answers, because they determine the recovery position for each class of data. For the promotion steps, period commit and restoration of the original master, follow the *Failing over a Ceph RGW multisite zone* runbook rather than repeating those steps here. Add an encrypted-object read test to that runbook's acceptance checks so that a failover is not declared complete until decryption works in the new master zone.

Limits to confirm before you commit to a design

Server-side encryption on Ceph RGW depends on three moving parts: the RGW release, the key backend and the applications that send encryption headers. Each card below names one item to verify and who should confirm it, so the design rests on documented support rather than assumptions.

Supported encryption modes per release

Confirm which of SSE-C, SSE-KMS and SSE-S3 your RGW release implements, and which algorithms it accepts for each. The release notes for your exact Ceph version decide this, not general S3 compatibility claims. Check whether your target release is in the actively maintained set before you commit. Confirm this with the Ceph documentation for the version you will run.

Key backend support for each mode

Confirm whether Vault, OpenBao, KMIP or Barbican is a supported key backend for the encryption mode you need, and which authentication method RGW uses against it. Support for one backend does not imply support for another. Ask the Ceph documentation for the backend list and the configuration keys required, and test the chosen backend against a non-production zone first.

Enterprise features for HSM and FIPS

If your requirements call for an HSM, PKCS#11 or FIPS-validated cryptography, confirm with the key manager vendor which features need a license. For HashiCorp Vault, HSM support, PKCS#11 provider and FIPS compliance are listed as Enterprise features that require a license applied to the cluster. Ask the vendor for the license scope, the edition that includes it and the validation status of the exact build you will deploy.

Key manager storage and availability

Confirm how the key manager's storage backend affects availability, because RGW cannot read encrypted objects while the key service is unreachable. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends for OpenBao, and HashiCorp recommends integrated storage for most Vault use cases. Ask the internal team to define the failure behavior, the backup and restore procedure for key material, and the recovery time that the business accepts.

Encrypting existing objects in place

Confirm whether existing unencrypted objects can be encrypted in place, or only new uploads receive encryption. Encryption settings usually apply to objects written after they are enabled, so plan a copy or rewrite job for historical data and budget the time it takes. Confirm the behavior with the Ceph documentation for your release, then have the internal team estimate the rewrite window against production traffic.

Client library header behavior

Confirm how the S3 SDKs and tools your applications use send encryption headers, including the customer-key headers that SSE-C requires and the MD5 digest of the key. Some libraries drop or rename headers, and some do not expose SSE-C at all. Have the internal team test each application's SDK version against a test bucket, and check that no client sends customer keys over plain HTTP.

Questions teams ask before encrypting RGW buckets

What drives the cost and effort of SSE-KMS for Ceph RGW?

The biggest driver is whether you already run a key manager that your storage team can use, because building or extending one changes the work more than the RGW configuration does. Other drivers are the high availability design of the key manager, whether you need an enterprise license with features such as performance replication or HSM support, how much testing you need across SDKs and applications, and how many multisite zones must share the same key behavior. Your costs split into one-time design, build and testing work, and recurring operation of the key manager and its backups. Ask any partner for a quote that lists each of these items separately, and ask your key manager vendor for current license terms, since HashiCorp publishes Vault Enterprise pricing only through sales.

How long does an RGW encryption rollout take?

The duration depends on the scope you agree in writing, not on a standard number, so this page does not give one. The main factors are how many buckets and applications must be tested, whether the key manager already meets your availability and backup requirements, whether a change window is needed for existing data, and how many Ceph zones are involved. Plan the rollout in stages: a design and key manager readiness review, a non-production test, a pilot bucket set, and then wider adoption. Ask for a timeline in the statement of work that ties each stage to a deliverable.

Which people from our team does an RGW encryption project need?

Expect to involve four groups. Storage administrators own the RGW configuration, the cluster and the rollout of encryption settings. Key manager administrators own the Vault, OpenBao or KMIP service, its policies, unseal or recovery procedures and backups. Application owners confirm which SDKs and clients send SSE headers and how they handle failures. Network and certificate owners handle HTTPS endpoints, proxy behavior and certificate trust between RGW and the key manager. Name one decision owner for key lifecycle and one for application impact before the work starts, because most delays come from unclear ownership of these two decisions.

Can our own team implement SSE-KMS on Ceph RGW without outside help?

A capable storage team with an experienced key manager team can often do the work in house, especially if the design is already decided and the test plan is simple. Outside help usually pays off in three places: choosing between SSE-C, SSE-KMS and SSE-S3 for each data class, designing key manager high availability and recovery so that a single failure does not block reads, and testing client behavior across the SDKs and tools your applications use. Ask a partner to show how they will verify each of these items, and check that your team keeps the runbooks afterward.

Are Vault and OpenBao interchangeable for RGW encryption?

Not automatically. OpenBao is a community fork of Vault under the MPL-2.0 license, but its migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so you should not assume Enterprise features or current Vault releases carry over. Before choosing, confirm with the project which API paths, auth methods and transit or key features your RGW configuration relies on, and test them against the exact version you plan to run. Also check the license terms of Vault for your use, since HashiCorp moved future releases to the Business Source License 1.1 and IBM is the licensor named in the Vault LICENSE file.

What happens to our objects if the key manager is lost?

Objects encrypted with keys held only in a lost key manager cannot be decrypted, so the data is effectively unavailable even though the Ceph cluster is intact. This is the main reason to design key backup, recovery and unseal procedures before the first object is written. Confirm how your chosen backend stores and backs up key material, who holds unseal or recovery credentials, and how often you test a restore into a separate environment. Write down the recovery order for the Ceph cluster, the key manager and the applications, and rehearse it.

How does SSE interact with lifecycle rules and replication?

Lifecycle rules operate on object metadata and timing, so expiration can still remove encrypted objects, but any transition to a remote tier must be checked for how encryption metadata and keys are handled. Replication between zones depends on the key manager being reachable and consistent in each zone, so a key that is missing or unreachable at the secondary can block reads or replication for affected objects. Test lifecycle transitions and multisite replication with encrypted buckets before rollout, and confirm the exact behavior with the Ceph Object Gateway documentation for your release.

Do we need HTTPS between clients, RGW and the key manager?

Yes, you should plan encrypted transport on every hop, because SSE-C requires the client to send the customer key in request headers that must not be exposed in transit. If a proxy or load balancer terminates TLS in front of RGW, confirm that it forwards the requests in a form RGW accepts and that it does not log or cache those headers. Also confirm certificate trust between RGW and the key manager, including certificate rotation. Review the cephadm-managed ingress and certificate options with your network team before enabling SSE for production buckets.

How DeployOpen scopes and delivers RGW encryption

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so RGW encryption is designed around your key management backend, your proxy layout and your multisite topology. Engagements are fixed-scope, with the written scope agreed before work starts.

How we scope

Confirm which encryption modes your applications need, and whether SSE-C, SSE-KMS or SSE-S3 fits each bucket class.
Identify the key management backend you already run, whether Vault, a KMIP server or Barbican, and its licensing and high availability model.
Map HTTPS termination points, proxies and multisite zones so the written scope names every path that carries encrypted requests.

How we build

Configure the RGW encryption settings and key backend connection in a staging cluster that mirrors your production topology.
Test AES-GCM and CBC behavior with your SDKs and clients, and confirm which ciphers your gateway accepts.
Verify key retrieval, failure handling and multisite consistency with planned tests before any production change.

How we hand over

Deliver configuration records, key lifecycle runbooks and the test results agreed in the written scope.
Document the SSE-C blocking decision, proxy requirements and recovery steps for a lost or unavailable key service.
Train your operations team on rotating credentials and reviewing encryption settings after cluster upgrades.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review key backend versions and Ceph release changes, such as Squid and Tentacle maintenance releases, before they reach production.
Re-run encryption checks after topology changes, including new zones, proxies or key backend migrations.

Ceph RGW server-side encryption with Vault, KMIP or Barbican