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.

Bring your own secret manager

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.

Running ArgoCD + HashiCorp Vault?

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.

Data flow

How injection works

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.

1. A pod presents its Kubernetes ServiceAccount token.
2. ESO authenticates to the secret manager using that identity (no static credentials).
3. Only the required secret is fetched, materialized into an in-memory (tmpfs) Kubernetes Secret, and mounted into the pod.
4. 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).

Tree

Vault backends

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).

Architecture

HSM-backed unseal

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.