Vault PKI
Portail > Mise en œuvre et exploitation
Le moteur de secrets PKI de HashiCorp Vault fait de Vault une autorité de certification dynamique : émission de certificats à la demande, TTL courts, automatisation. Il s'intègre directement à cert-manager.
Architecture recommandée
On sépare la racine et l'émettrice, comme en PKI classique :
- une racine hors ligne ou dans un montage PKI dédié, idéalement adossée à un HSM ;
- une ou plusieurs intermédiaires (montages PKI distincts) signées par la racine, qui émettent les feuilles.
<mermaid> flowchart TB
R["Montage pki_root
(racine, usage rare)"] -->|signe la CSR| I["Montage pki_int
(intermédiaire)"] I -->|issue| L["Feuilles
(TTL courts)"]
</mermaid>
(Schéma en Mermaid.)
Mise en place (résumé)
# Racine
vault secrets enable -path=pki_root pki
vault secrets tune -max-lease-ttl=87600h pki_root
vault write -field=certificate pki_root/root/generate/internal \
common_name="Nexiat Root CA" ttl=87600h > root.crt
# Intermédiaire : génère une CSR, signée par la racine
vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int
vault write -field=csr pki_int/intermediate/generate/internal \
common_name="Nexiat Issuing CA" > int.csr
vault write -field=certificate pki_root/root/sign-intermediate \
csr=@int.csr format=pem_bundle ttl=43800h > int.crt
vault write pki_int/intermediate/set-signed certificate=@int.crt
Rôles : la politique d'émission
Un rôle borne ce que l'émettrice peut délivrer (contraintes appliquées à l'émission) :
vault write pki_int/roles/clipsy \
allowed_domains="clipsy.tech" \
allow_subdomains=true \
max_ttl=2160h \
key_type=rsa key_bits=3072 \
server_flag=true client_flag=false
# Émission
vault write pki_int/issue/clipsy common_name="api.clipsy.tech" ttl=2160h
Le rôle fixe domaines autorisés, TTL maximal, type/longueur de clé, usages (server/client). C'est l'équivalent opérationnel des contraintes vues côté théorie.
Révocation, CRL, OCSP
Vault gère la révocation (pki_int/revoke), publie une CRL et expose un répondeur OCSP. Configurer les URLs (config/urls) pour renseigner correctement les extensions AIA/CDP des certificats émis.
Intégration cert-manager
cert-manager dispose d'un Issuer Vault : il appelle l'endpoint issue du rôle, et Vault renvoie la feuille + la chaîne. On garde le déclaratif Kubernetes tout en centralisant la CA dans Vault.
Sécurité des clés
- Managed keys (Vault Enterprise) : la clé de CA réside dans un HSM via PKCS#11 et ne sort jamais de Vault/HSM.
- Seal wrap pour protéger les données sensibles au repos.
- Racine de TTL long mais d'usage rare ; intermédiaires renouvelées régulièrement (Cycle de vie d'un certificat).
Points clés à retenir
- Vault = CA dynamique : racine + intermédiaire(s) en montages PKI séparés.
- Les rôles encadrent l'émission (domaines, TTL, clé, usages).
- Vault publie CRL/OCSP ; bien configurer les URLs AIA/CDP.
- Intégration native avec cert-manager ; clés de CA protégeables par HSM (managed keys).