The Key Manager (Barbican) secret store backend determines how secret payloads are encrypted and where ciphertext is stored. Polystack Key Manager supports five backend types — from a software-only AES plugin for development, to hardware HSMs, external KMIP servers, HashiCorp Vault, and Dogtag KRA for enterprise deployments. Configuration is managed through the deployment console; changing the backend after secrets exist requires a migration operation.
Administrator Access Required — This operation requires the admin role. Contact your
Polystack administrator if you do not have sufficient permissions.
Software-based AES-256 encryption. The Key Encryption Key (KEK) is base64-encoded and stored in barbican.conf. Secrets are encrypted at rest in the Barbican database.
32-byte AES key, base64-encoded — protects all project KEKs
The kek value is stored in plaintext in barbican.conf. Any host compromise exposes all secrets. This backend is suitable only for development and testing environments. Use PKCS#11, KMIP, or Vault for production.
Stores the Master KEK and HMAC signing key inside a hardware HSM. Per-project KEKs are wrapped by the MKEK and signed with HMAC before being stored in the database. Supports Thales Luna, nCipher nShield, ATOS Bull, and Utimaco HSMs.
mkek_label and hmac_label must be different values. Identical labels cause authentication failures.
Secrets are stored directly on the external KMIP device — Barbican’s database holds only a reference/locator. Supports mutual TLS authentication. Compatible with any OASIS KMIP-compliant server.
barbican.conf
[secretstore]enabled_secretstore_plugins = kmip_plugin[kmip_plugin]host = kmip.internal.<your-domain>port = 5696keyfile = /etc/barbican/certs/client.keycertfile = /etc/barbican/certs/client.crtca_certs = /etc/barbican/certs/ca.crt# Optional: username/password if required by the KMIP deviceusername = barbican-svcpassword = <kmip-password>
Parameter
Description
host
KMIP server hostname or IP
port
KMIP port (default 5696)
keyfile
Client TLS private key path
certfile
Client TLS certificate path
ca_certs
CA certificate for server validation
username
KMIP authentication username (optional)
password
KMIP authentication password (optional)
Client certificates and private keys must be readable only by the barbican service user (chmod 0400). Store them on an encrypted volume.
Secrets are stored in Vault’s KV secrets engine. Barbican authenticates using either a root token (development) or AppRole (production). The Vault server can be self-hosted or HCP Vault.
barbican.conf
[secretstore]enabled_secretstore_plugins = vault_plugin[vault_plugin]vault_url = https://vault.internal.<your-domain>:8200use_ssl = truessl_ca_crt_file = /etc/barbican/certs/vault-ca.crt# Production: use AppRole (recommended)approle_role_id = <vault-role-id>approle_secret_id = <vault-secret-id>kv_mountpoint = secret# Development only (not recommended for production):# root_token_id = <vault-root-token>
Parameter
Description
vault_url
Vault server address
use_ssl
Enable TLS for Vault communication
ssl_ca_crt_file
CA certificate for Vault TLS verification
approle_role_id
AppRole role ID (recommended for production)
approle_secret_id
AppRole secret ID paired with role ID
kv_mountpoint
KV secrets engine mount point (default: secret)
root_token_id
Root token auth — development only
Use AppRole authentication in production. Root token auth works but is not rotatable and grants full Vault access. AppRole provides scoped, rotatable credentials.
Integrates with Red Hat Certificate System’s Key Recovery Authority. Secrets are stored in the KRA with master keys held in an NSS certificate database (software) or HSM. Supports optional FreeIPA integration.
Dogtag is the only backend offering software-HSM security (NSS database) without requiring physical HSM hardware. It is the recommended middle ground between Simple Crypto (no hardware) and PKCS#11 (requires HSM).
Comma-separated list — each maps to a [secretstore:SUFFIX] section
global_default = True
Exactly one backend must have this — handles secrets with no project preference
enabled_secretstore_plugins
Ignored when multi-backend mode is active
When switching from single-backend to multi-backend, keep the existing backend configuration as the global_default to maintain access to existing secrets.
