Secret Manager Integration
DuoKey is designed to plug into the secret manager you already operate, rather than forcing you to adopt a new one. Secrets are never hardcoded, never committed to Git, and never written to cluster disk — they are fetched on demand and held in memory only.
If your organization already standardizes on HashiCorp Vault, CyberArk, or a network HSM, DuoKey consumes secrets from it directly. The bundled OpenBao instance is the default for greenfield sites and can be omitted entirely.
Supported secret managers
| Secret manager | Integration path | Status |
|---|---|---|
| OpenBao (default) | External Secrets Operator (Kubernetes auth) | Recommended default |
| HashiCorp Vault | External Secrets Operator / Vault Agent Injector | Fully supported |
| CyberArk (Conjur / AAM / CCP) | External Secrets Operator (Conjur provider) | Fully supported |
| Azure Key Vault | External Secrets Operator / CSI Secrets Store | Supported (connected sites) |
| AWS Secrets Manager / GCP Secret Manager | External Secrets Operator | Supported (connected sites) |
| Kubernetes Secrets (encrypted etcd) | Native | Fallback / lab only |
The table above covers connection secrets and credentials. The cryptographic keys are held by a separate vault backend — see Key custody below.
How injection works
DuoKey uses the External Secrets Operator (ESO) as a vendor-neutral broker. Your secret manager remains the single source of truth; ESO synchronizes only the specific values a pod needs, on demand.
If your platform standardizes on ArgoCD for GitOps and HashiCorp Vault
(or OpenBao) as the secret store, see
GitOps Secret Delivery for the detailed,
manifest-by-manifest version of this pattern — including the Vault-side
auth/policy setup and the exact SecretStore/ExternalSecret objects your
Git repository holds.
A pod presents its ServiceAccount token to the External Secrets Operator, which authenticates to your secret manager, fetches only the required value, and materializes it as an in-memory Kubernetes Secret mounted into the pod.
- A pod presents its Kubernetes ServiceAccount token.
- ESO authenticates to the secret manager using that identity (no static credentials).
- Only the required secret is fetched, materialized into an in-memory
(
tmpfs) Kubernetes Secret, and mounted into the pod. - When the pod terminates, the secret is gone — nothing persists to disk.
Example: HashiCorp Vault SecretStore
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: vault
namespace: duokey
spec:
provider:
vault:
server: "https://vault.corp.example.local:8200"
path: "duokey"
version: "v2"
auth:
kubernetes:
mountPath: "kubernetes"
role: "duokey"
serviceAccountRef:
name: "duokey"
Example: CyberArk Conjur SecretStore
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: conjur
namespace: duokey
spec:
provider:
conjur:
url: "https://conjur.corp.example.local"
auth:
jwt:
account: "myConjurAccount"
serviceID: "openshift"
serviceAccountRef:
name: "duokey"
Key custody: vault backends
The cryptographic keys are held by a configurable vault backend in the Cockpit API — distinct from the credential secret manager above. Pick one during scoping:
- Software Vault (default) — the built-in key-custody backend used out of the box; no external cluster or hardware to provision.
- DuoKey MPC KMS (optional) — DuoKey's own multi-party-computation cluster of 3 or more nodes, deployed as part of your on-premise stack. Each key is split into shares so no single node ever holds a complete key, and operations are computed jointly across the nodes. No single point of compromise, no third-party TSM.
- Securosys HSM (optional) — a hardware root of trust via PKCS#11 / KMIP (below).
The Cockpit API selects a configurable vault backend for key custody: the built-in Software Vault by default, or an optional DuoKey MPC KMS cluster or Securosys HSM.
Optional: Securosys HSM
Where a hardware root of trust is mandated (e.g. by policy or certification), DuoKey integrates with Securosys HSM:
- Vendor: Securosys (Primus HSM / Securosys Cloud HSM).
- Interfaces: PKCS#11 and KMIP.
- Usage: the secret engine (OpenBao/Vault) seals/unseals against the Securosys HSM, so master key material never exists in plaintext outside the HSM boundary. MPC and the HSM can be combined for defense-in-depth.
- Network: place the HSM on a dedicated, hardened VLAN (see Network Security).
OpenBao (or Vault) seals and unseals against the Securosys HSM over PKCS#11 or KMIP, so master key material never exists in plaintext outside the HSM boundary.
Best practices
- Prefer dynamic, short-lived credentials over static ones wherever your secret manager supports them.
- Scope each
SecretStore/role to the least privilege required. - Rotate secret-manager auth roles and audit access regularly (see Compliance & Audit).
- For air-gapped sites, keep the secret manager and HSM fully on-premise; no outbound connectivity is required.