Enterprise Secrets Management (Barbican)
Okustera Secrets Management is powered by OpenStack Barbican, a dedicated secrets storage and cryptographic key management service designed for secure multi-tenant cloud infrastructure.
Safely generate, store, and manage symmetric encryption keys, asymmetric keypairs, TLS certificates, and application secrets with hardware-backed encryption.
Architectural Highlights
- Hardware-Backed Encryption: Master encryption keys (KEKs) stored in Hardware Security Modules (HSMs) or enterprise KMS vaults.
- Volume Encryption: Direct native integration with OpenStack Cinder and Ceph to provide transparent AES-256 block storage volume encryption-at-rest.
- Dynamic Secret Rotation: Automate scheduled rotation of API keys, database credentials, and TLS certificates without service interruption.
- Kubernetes Integration: Synchronize secrets securely into Kubernetes pods as native Secret resources using external-secrets operators.
Managing Secrets in the Cloud Portal
The Okustera Cloud Portal (/barbican) provides an interactive secrets management vault for developers:
1. Creating a Secret in the Vault
- Navigate to Security $\to$ Secrets Vault (
/barbican) in the left sidebar. - Click Store Secret:
- Secret Name: e.g.,
prod-db-password - Secret Type:
passphrase: Plaintext database passwords, API tokens, webhook secrets.symmetric: Cryptographic AES-256 keys for Ceph S3 default bucket encryption.certificate: X.509 server certificates or CA bundles.opaque: Binary blobs or encoded private credentials.
- Payload: Enter or paste the secret value.
- Algorithm & Bit Length: e.g.,
aes/256(for symmetric keys). - Expiration Date: Optionally set a calendar expiration to trigger rotation alerts.
- Secret Name: e.g.,
- Click Store Secret.
2. Inspecting and Copying Secret Payloads
- Secret payloads are masked by default in the portal to prevent screen-capture leakage.
- Click View Payload to reveal the plaintext or click the Copy icon to copy directly into your clipboard.
Storing and Retrieving Secrets via CLI
# 1. Store a database password secret
openstack secret store \
--name "prod-db-password" \
--secret-type "passphrase" \
--payload "<YOUR_SECRET_PAYLOAD>"
# 2. Retrieve secret metadata
openstack secret get $(openstack secret list -f value -c "Secret href")
# 3. Retrieve decrypted payload
openstack secret payload get <secret-href>
Kubernetes Secret Integration (External Secrets)
Application secrets stored in OpenStack Barbican can be dynamically synchronized into Kubernetes native Secret resources using the External Secrets Operator with a Barbican backend provider:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: app-db-secret
namespace: default
spec:
refreshInterval: 1h
secretStoreRef:
name: barbican-store
kind: ClusterSecretStore
target:
name: db-credentials
creationPolicy: Owner
data:
- secretKey: password
remoteRef:
key: prod-db-password
Storage Encryption at Rest (Ceph S3 SSE-KMS)
Barbican acts as the centralized Key Management Service (KMS) for Ceph RADOS Gateway (RGW) automated Server-Side Encryption (SSE-KMS):
# 1. Create a 256-bit AES symmetric key in Barbican
KEY_SECRET=$(openstack secret store \
--name "s3-sse-kms-lake-key" \
--secret-type "symmetric" \
--algorithm "aes" \
--bit-length 256 \
--mode "cbc" \
--payload "$(openssl rand -base64 32)" \
--payload-content-type "text/plain" \
-f value -c "Secret href")
echo "Created Barbican KMS Secret: $KEY_SECRET"
# 2. Extract UUID for Ceph S3 default bucket configuration
KEY_UUID=$(echo "$KEY_SECRET" | awk -F'/' '{print $NF}')
echo "KMS Key UUID: $KEY_UUID"
Ceph RGW uses this Barbican key via Keystone authentication tokens to generate per-object Data Encryption Keys (DEKs) on the fly, guaranteeing zero-trust cryptographic isolation at rest.
Block Storage Volume Encryption & Tenant Crypto-Shredding (Cinder LUKS)
Okustera Cinder integrates natively with Barbican KMS to provide transparent, hardware-accelerated LUKS (Linux Unified Key Setup) volume encryption at rest for persistent block storage.
1. Volume Type Architecture & Key Escrow
Block storage volumes provisioned under the LUKS volume type are encrypted using standard aes-xts-plain64 with a 256-bit symmetric key:
- Key Generation: When a tenant requests a volume of type
LUKS, Cinder invokes Barbican KMS via the OpenStack Castellan key manager to automatically generate a dedicated 256-bit AES symmetric key. - Front-End Control Location: Encryption is handled directly by the hypervisor kernel (
nova.volume.encryptors.luks.LuksEncryptor) using host AES-NI instructions, ensuring data is encrypted before writing to the Ceph RBD backend. - Verifiable Tenant Crypto-Shredding: When an encrypted volume is deleted, Barbican KMS automatically shreds and purges the associated encryption key from its vault. The underlying storage blocks in Ceph RBD become mathematically unrecoverable, providing verifiable cryptographic erasure compliance with GDPR Article 17 (Right to Erasure) and NIST SP 800-88.
2. Creating & Using Encrypted Volumes
# Provision a 10 GB encrypted LUKS volume
openstack volume create \
--size 10 \
--type LUKS \
--description "Encrypted database volume with Barbican KMS key escrow" \
tenant-encrypted-vol
# Verify encryption metadata and Barbican key association
openstack volume show tenant-encrypted-vol \
-c id -c name -c encrypted -c encryption_key_id -c status
Output:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| encrypted | True |
| encryption_key_id | 7fc03b98-c64a-40cc-87e8-573b48dcfd88 |
| id | f7a5c65f-8587-459d-a6f3-9a4ba3b3dfd2 |
| name | tenant-encrypted-vol |
| status | available |
+-------------------+--------------------------------------+
In-Transit Mesh & Storage Wire Encryption
Okustera enforces defense-in-depth encryption across all internal and cross-node communication channels:
- Pod-to-Pod Transparent Mesh Encryption (Cilium WireGuard):
- All inter-node traffic across the Kubernetes cluster is transparently encrypted at the kernel level using WireGuard (
cilium_wg0, port 51871). - Curve25519 public keys are exchanged securely via Cilium node custom resources with automatic re-keying and zero MTU degradation.
- All inter-node traffic across the Kubernetes cluster is transparently encrypted at the kernel level using WireGuard (
- Ceph Messenger v2 In-Transit Storage Encryption:
- Internal storage cluster traffic across Monitor, Manager, and OSD daemons enforces secure mode (
ms_cluster_mode: secure,ms_service_mode: secure), preventing packet snooping across HCI physical interconnects.
- Internal storage cluster traffic across Monitor, Manager, and OSD daemons enforces secure mode (
- Public Ingress TLS 1.3:
- Edge traffic terminated at Apache APISIX and Ingress NGINX enforces mandatory modern TLS 1.3 cipher suites.
Virtual TPM 2.0 (vTPM) & Measured Boot for Tenant VMs
Hypervisor compute nodes equip the software-emulated TPM 2.0 engine (swtpm) integrated with QEMU/KVM via libvirt:
- Measured Boot & Attestation: Allows Nova instances and Magnum tenant Kubernetes nodes to establish cryptographic root-of-trust, measuring kernel and boot stages.
- Guest BitLocker & LUKS Passphrase Storage: Tenant VMs can securely store LUKS passphrases and Windows BitLocker sealed keys inside the virtual security chip without exposing secrets in guest memory or storage disks.
- Flavor & Image Activation: Request vTPM 2.0 support by setting image or flavor metadata:
openstack image set --property hw_tpm_model=tpm-crb --property hw_tpm_version=2.0 <IMAGE_ID>
REST API Reference
GET /api/v1/barbican/secrets— List secrets in current tenant project.POST /api/v1/barbican/secrets— Store a new secret (payload, type, algorithm).GET /api/v1/barbican/secrets/{id}/payload— Retrieve decrypted secret payload.DELETE /api/v1/barbican/secrets/{id}— Permanently delete a secret from vault (crypto-shredding).