Skip to main content

​
Overview

Key Manager supports multiple simultaneous secret store backends. Different stores can be assigned to different projects, providing tiered security levels — e.g., routing regulated projects to HSM-backed storage while using software crypto for development projects.
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.

​
List Secret Stores

List all configured secret stores
openstack secret store list
Show the platform-default secret store
openstack secret store get preferred

​
Assign a Store to a Project

Assign a specific secret store to a project to override the platform default:
Set preferred store for a project
openstack secret store set preferred \
  --secret-store-id <store-id>
Show the preferred store for a project
openstack secret store get preferred --project <project-id>
Reset to platform default
openstack secret store unset preferred
Changing a project’s preferred store does not migrate existing secrets. Secrets created before the change remain in the original store. Only new secrets use the newly assigned store.

​
Multi-Store Design Patterns

PatternConfigurationUse Case
Single store (default)One simple_crypto or PKCS#11 backendHomogeneous environment
Tiered securitysimple_crypto for dev, PKCS#11 for productionPCI-DSS, HIPAA, regulated workloads
Geographic isolationPer-region KMIP servers as separate storesData residency requirements
Workload separationHSM store for TLS keys, software store for API tokensCost optimization

​
Migration Between Stores

Migrating existing secrets from one store to another is a manual process:
1

Retrieve existing secrets

Export all secret payloads from the current store. This requires read access to every secret in the project.
2

Assign the new store to the project

Set new preferred store
openstack secret store set preferred \
  --secret-store-id <new-store-id>
3

Re-create secrets in the new store

Store each payload as a new secret. The new secrets will be encrypted by the new store.
4

Update all references

Update any services, Load Balancer listeners, or containers that reference the old secret HREFs to point to the new secret HREFs.
5

Delete old secrets

Once all references are updated and verified, delete the original secrets from the old store.

​
Next Steps

Backend Configuration

Configure the underlying backend for each secret store

Transport Keys

Manage RSA transport keys for client-side encryption

Security

Apply hardening policies for each store type

Quotas

Set per-project limits for secret creation