OpenStack Barbican key manager

The encrypted volume path starts when a user creates a volume from a volume type that has encryption enabled. The Cinder API accepts the request and hands it to the volume service, which asks Barbican to create a symmetric key secret, or uses an existing key if the request names one. Both sides authenticate through Keystone: the user's token authorizes the original request, and the Cinder service user's credentials authorize the internal calls. Cinder records only the secret identifier in its database and in the volume's encryption metadata, so the key material stays in Barbican. The key is requested again at attach time, because the compute host needs it to open the encrypted device. Confirm this sequence in your release before you design around it.

A TLS listener follows a similar pattern with different ownership. The certificate, private key and any intermediate chain are stored in Barbican as a secret container, and the listener request refers to that container by its identifier. Octavia's controller services use their Keystone service credentials to read the container when they build or reconfigure the amphora, then push the material into the load balancer instance over its management path. The Octavia database keeps references to the secret, not a copy of the private key. Ask your team to confirm how the release handles certificate rotation, whether an updated container is picked up automatically or needs a listener update, and which secret formats it accepts.

Responsibility for this flow is split across three owners, and the gaps tend to sit between them. Barbican enforces access through secret ACLs and project roles, but it does not decide which keys should exist or when they should rotate. Cinder and Octavia decide when to request and read secrets, but the operator chooses the key manager backend, the service user roles and the retention rules. Loss of the Barbican database or its crypto backend can make encrypted volumes unreadable and break listeners, so backup and restore of Barbican need the same planning as the workloads that depend on it. Name one owner for each of these decisions before the build starts.

Treat the flow described above as a working hypothesis until you have run it in your own release and configuration. Check the Cinder and Octavia configuration references for the key manager and certificate settings that apply to your version, and confirm the Barbican version you run. Then test the path end to end in a non-production project: create an encrypted volume, attach it, inspect the secret ACLs granted to the service users, and remove one service user's access to confirm that attach fails in the expected way. Repeat the TLS test with a rotated certificate. Record the results so your change board can reproduce them after each upgrade.

The first decision in a Barbican deployment is where secret and key material physically sits and which back end holds it. Barbican is a front end that stores secrets, keys and certificates through a pluggable secret store back end, so this choice determines who can read key material, how it is backed up, and how it is recovered after a failure. Treat the back end as a design decision with compliance and operational consequences, not as a default to accept during installation. There are two broad positions. In software-based storage inside the cloud, the encrypted secret material lives in a database or storage service that your OpenStack control plane operates, typically protected by a master key that the cloud itself can reach. This keeps the operational footprint small and fits the rest of your infrastructure, but operators with sufficient access to the control plane, its database or its configuration may be able to reach key material. In externally held key material, a hardware security module or an external key service holds the master keys, and Barbican requests cryptographic operations from it. That separates key custody from cloud administration, at the cost of an additional system to size, connect, monitor and keep available.

Each position changes backup and recovery. With in-cloud storage, backups of the Barbican database must be treated as sensitive, because a copy of the encrypted secrets plus access to the master key material is equivalent to access to the secrets. Restores have to recover the database and the key wrapping configuration together, and you should rehearse that restore on a separate environment. With externally held keys, losing the external key service can make secrets unreadable even when the database is intact, so backup planning must cover the external system, its own disaster recovery and the credentials Barbican uses to reach it. Ask the vendor or the project which backup procedure the chosen back end requires and whether key material can be exported. Before committing, list the back ends your OpenStack release supports and check each one against the Barbican documentation for that release. Do not assume a back end is available because it appears in a general list. Confirm with the project or your vendor which back ends the release includes, which versions of any external hardware module or key service it works with, and which features such as key rotation, encryption of stored secrets and high availability each one supports. Record the answers in the design document, because they constrain the Keystone roles and the audit trail covered in the access policy section.

Settle project-level access before any production secret is stored in Barbican, because the access model is much harder to change once Cinder volumes and Octavia listeners depend on it. Barbican checks each request against the caller's Keystone token, project and roles, and applies its policy rules to secrets, containers and their access control lists. Decide which roles may create, read, update and delete secrets in each project, and document that mapping. Role names and default policy rules can change between OpenStack releases, so confirm them against the Barbican policy documentation for the release you will run, then test each role with a non-administrative account before go-live.

Keep ownership and consumer access as separate decisions. The project that creates a secret owns it and can manage its access control list. A consumer such as a Cinder back end, an Octavia controller or an application service account needs read access that is granted explicitly, usually by naming the consuming user or project in the secret's access control list. Avoid granting read access to whole projects when a single service user will do. Ask the team to produce a list of every secret, its owner and each consumer, and to justify any entry that allows broad reads. This list becomes the baseline for the access review you will run after handover.

Define how certificates are renewed before they expire. Barbican stores certificate material and can carry expiration metadata, but confirm whether your release enforces expiry or only records it, because that determines whether an expired certificate can still be served. Updating a secret in Barbican does not automatically reconfigure every listener that uses it. Confirm with your Octavia documentation and test the reload path in a staging environment. Set a renewal lead time, a named owner for each certificate, and a rotation procedure that creates the new secret, switches the listener and then retires the old secret only after traffic is confirmed healthy.

Plan deletion and retirement as a dependency exercise. Deleting a secret that serves as a Cinder volume encryption key can leave encrypted volumes unreadable, and a deleted key cannot be recovered from Barbican alone. Before any deletion, inventory the volumes, images and listeners that reference the key, and confirm that a recoverable copy exists in the secret store back end's own backup process. Disable or stop using a key in a controlled window before removing it, and agree on who approves each deletion. Ask your team to confirm how the configured back end handles key material on deletion, since this varies with the back end you choose.

After handover, the client team owns the runbook. It should cover the key creation and naming standard, the access control list review cadence, a dashboard or report of upcoming certificate expiries, the rotation calendar, the restore test for the secret store back end, the response steps for a suspected key compromise, and a policy check after each OpenStack upgrade. DeployOpen can prepare the configuration, documentation and evidence for these controls, but independent auditors and certification bodies decide whether the controls meet any compliance requirement. Ask any assessor which evidence they expect before the runbook is finalized.