Secret-Manager-Integration

DuoKey ist so konzipiert, dass es sich in den Secret-Manager einfügt, den Sie bereits betreiben, anstatt Sie zur Einführung eines neuen zu zwingen. Secrets werden niemals fest im Code hinterlegt, niemals in Git committet und niemals auf die Cluster-Festplatte geschrieben — sie werden bei Bedarf abgerufen und nur im Speicher gehalten.

Bringen Sie Ihren eigenen Secret-Manager mit

Wenn Ihre Organisation bereits auf HashiCorp Vault, CyberArk oder ein Netzwerk-HSM standardisiert ist, bezieht DuoKey Secrets direkt daraus. Die mitgelieferte OpenBao-Instanz ist die Vorgabe für Greenfield-Standorte und kann vollständig weggelassen werden.

Unterstützte Secret-Manager

Secret-Manager	Integrationsweg	Status
OpenBao (Standard)	External Secrets Operator (Kubernetes-Auth)	Empfohlene Vorgabe
HashiCorp Vault	External Secrets Operator / Vault Agent Injector	Vollständig unterstützt
CyberArk (Conjur / AAM / CCP)	External Secrets Operator (Conjur-Provider)	Vollständig unterstützt
Azure Key Vault	External Secrets Operator / CSI Secrets Store	Unterstützt (verbundene Standorte)
AWS Secrets Manager / GCP Secret Manager	External Secrets Operator	Unterstützt (verbundene Standorte)
DuoKey MPC	Nativ (verteilte Schlüsselanteile)	Primärer Vertrauensanker — kein HSM erforderlich
Securosys HSM	PKCS#11, KMIP	Unterstützt (Hardware-Vertrauensanker)
Kubernetes Secrets (verschlüsseltes etcd)	Nativ	Nur als Fallback / Labor

So funktioniert die Injektion

DuoKey verwendet den External Secrets Operator (ESO) als herstellerneutralen Broker. Ihr Secret-Manager bleibt die einzige Quelle der Wahrheit; ESO synchronisiert nur die spezifischen Werte, die ein Pod benötigt, bei Bedarf.

1. Ein Pod präsentiert sein Kubernetes-ServiceAccount-Token.
2. ESO authentifiziert sich mit dieser Identität beim Secret-Manager (keine statischen Anmeldedaten).
3. Nur das erforderliche Secret wird abgerufen, in einem In-Memory-Kubernetes-Secret (tmpfs) materialisiert und in den Pod eingebunden.
4. Wenn der Pod beendet wird, ist das Secret verschwunden — nichts wird auf der Festplatte persistiert.

Beispiel: 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"

Beispiel: 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"

Schlüsselverwahrung: MPC zuerst

Das Kernunterscheidungsmerkmal von DuoKey — und sein primärer Vertrauensanker — ist Multi-Party Computation (MPC). Schlüsselmaterial wird in unabhängige Anteile aufgeteilt, sodass kein einzelner Knoten und kein einzelner Administrator jemals einen vollständigen Schlüssel besitzt. Dies bietet Schlüsselschutz auf HSM-Niveau ohne dedizierte HSM-Hardware, was ideal für On-Premise- und Air-Gap-Bereitstellungen ist.

• Der Secret-Manager schützt Verbindungs-Secrets und Anmeldedaten.
• DuoKey MPC schützt die kryptografischen Schlüssel selbst, mit verteilter Verwahrung und ohne einzelnen Kompromittierungspunkt.

Optional: Securosys HSM

Wo ein Hardware-Vertrauensanker vorgeschrieben ist (z. B. durch Richtlinie oder Zertifizierung), integriert sich DuoKey in das Securosys-HSM:

• Hersteller: Securosys (Primus HSM / Securosys Cloud HSM).
• Schnittstellen: PKCS#11 und KMIP.
• Verwendung: Die Secret-Engine (OpenBao/Vault) versiegelt/entsiegelt gegen das Securosys-HSM, sodass Master-Schlüsselmaterial niemals im Klartext außerhalb der HSM-Grenze existiert. MPC und HSM können für mehrschichtige Verteidigung kombiniert werden.
• Netzwerk: Platzieren Sie das HSM in einem dedizierten, gehärteten VLAN (siehe Netzwerksicherheit).

Bewährte Praktiken

• Bevorzugen Sie dynamische, kurzlebige Anmeldedaten gegenüber statischen, wo immer Ihr Secret-Manager dies unterstützt.
• Beschränken Sie jeden SecretStore/jede Rolle auf die erforderlichen minimalen Rechte.
• Rotieren Sie die Auth-Rollen des Secret-Managers und auditieren Sie den Zugriff regelmäßig (siehe Compliance & Audit).
• Halten Sie für Air-Gap-Standorte den Secret-Manager und das HSM vollständig on-premise; es ist keine ausgehende Konnektivität erforderlich.