Intégration du gestionnaire de secrets

DuoKey est conçu pour s'intégrer au gestionnaire de secrets que vous exploitez déjà, plutôt que de vous forcer à en adopter un nouveau. Les secrets ne sont jamais codés en dur, jamais commités dans Git et jamais écrits sur le disque du cluster — ils sont récupérés à la demande et conservés uniquement en mémoire.

Apportez votre propre gestionnaire de secrets

Si votre organisation s'appuie déjà sur HashiCorp Vault, CyberArk ou un HSM réseau, DuoKey consomme les secrets directement à partir de celui-ci. L'instance OpenBao fournie est la valeur par défaut pour les sites greenfield et peut être entièrement omise.

Gestionnaires de secrets pris en charge

Gestionnaire de secrets	Voie d'intégration	Statut
OpenBao (par défaut)	External Secrets Operator (auth Kubernetes)	Valeur par défaut recommandée
HashiCorp Vault	External Secrets Operator / Vault Agent Injector	Entièrement pris en charge
CyberArk (Conjur / AAM / CCP)	External Secrets Operator (fournisseur Conjur)	Entièrement pris en charge
Azure Key Vault	External Secrets Operator / CSI Secrets Store	Pris en charge (sites connectés)
AWS Secrets Manager / GCP Secret Manager	External Secrets Operator	Pris en charge (sites connectés)
DuoKey MPC	Natif (parts de clé distribuées)	Racine de confiance principale — aucun HSM requis
Securosys HSM	PKCS#11, KMIP	Pris en charge (racine de confiance matérielle)
Kubernetes Secrets (etcd chiffré)	Natif	Solution de repli / laboratoire uniquement

Fonctionnement de l'injection

DuoKey utilise l'External Secrets Operator (ESO) comme courtier neutre vis-à-vis des fournisseurs. Votre gestionnaire de secrets reste la source unique de vérité ; l'ESO ne synchronise que les valeurs spécifiques dont un pod a besoin, à la demande.

1. Un pod présente son jeton de ServiceAccount Kubernetes.
2. L'ESO s'authentifie auprès du gestionnaire de secrets à l'aide de cette identité (aucun identifiant statique).
3. Seul le secret requis est récupéré, matérialisé dans un Secret Kubernetes en mémoire (tmpfs) et monté dans le pod.
4. Lorsque le pod se termine, le secret disparaît — rien n'est persisté sur le disque.

Exemple : SecretStore HashiCorp Vault

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"

Exemple : SecretStore CyberArk Conjur

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"

Garde des clés : le MPC d'abord

Le facteur de différenciation clé de DuoKey — et sa racine de confiance principale — est le calcul multipartite (Multi-Party Computation, MPC). Le matériel de clé est divisé en parts indépendantes de sorte qu'aucun nœud unique, et aucun administrateur unique, ne détient jamais une clé complète. Cela offre une protection des clés de niveau HSM sans nécessiter de matériel HSM dédié, ce qui est idéal pour les déploiements on-premise et air-gap.

• Le gestionnaire de secrets protège les secrets et identifiants de connexion.
• Le MPC de DuoKey protège les clés cryptographiques elles-mêmes, avec une garde distribuée et aucun point unique de compromission.

Optionnel : HSM Securosys

Lorsqu'une racine de confiance matérielle est imposée (par exemple par une politique ou une certification), DuoKey s'intègre au HSM Securosys :

• Fournisseur : Securosys (Primus HSM / Securosys Cloud HSM).
• Interfaces : PKCS#11 et KMIP.
• Usage : le moteur de secrets (OpenBao/Vault) réalise le scellement/descellement (seal/unseal) contre le HSM Securosys, de sorte que le matériel de clé maître n'existe jamais en clair en dehors de la frontière du HSM. Le MPC et le HSM peuvent être combinés pour une défense en profondeur.
• Réseau : placez le HSM sur un VLAN dédié et renforcé (voir Sécurité réseau).

Bonnes pratiques

• Préférez des identifiants dynamiques et à courte durée de vie aux identifiants statiques partout où votre gestionnaire de secrets le permet.
• Limitez chaque SecretStore/rôle au moindre privilège requis.
• Faites tourner les rôles d'authentification du gestionnaire de secrets et auditez régulièrement les accès (voir Conformité et audit).
• Pour les sites air-gap, conservez le gestionnaire de secrets et le HSM entièrement on-premise ; aucune connectivité sortante n'est requise.