Kubernetes vault

Fiche express
Type	Référence opérationnelle CLI pour l'administration d'un cluster Vault
Périmètre	Cycle de vie des tokens, scellement, sauvegarde/restauration Raft
Prérequis	Vault ≥ 1.10, stockage intégré Raft (les commandes CLI restent globalement valables au-delà, à vérifier)
Voir aussi	Vault

Cette page est un aide-mémoire opérationnel pour l'administration d'un cluster Vault en ligne de commande (vault CLI) : gestion fine des tokens, scellement/descellement, et surtout sauvegarde/restauration via les snapshots Raft — des opérations de conduite courante qui reviennent, entre autres, lorsque Vault sert de backend de secrets à des workloads Kubernetes (via la méthode d'authentification Kubernetes décrite sur la page Vault). Les concepts généraux de Vault — moteurs de secrets, méthodes d'authentification, politiques, licence — sont couverts sur la page Vault et ne sont pas répétés ici.

Sauf mention contraire, les valeurs entre chevrons (<...>) sont à remplacer par vos propres valeurs, et VAULT_ADDR doit pointer vers votre serveur :

export VAULT_ADDR='https://vault.exemple.local:8200'
export VAULT_CACERT='/etc/vault/ca.pem'   # si TLS auto-signé

vault status

Authentification et token courant

vault login authentifie l'utilisateur et écrit le token obtenu dans ~/.vault-token, lu automatiquement par les commandes suivantes (ou via la variable VAULT_TOKEN) :

vault login <token>                                  # par token existant
vault login -method=userpass username=<utilisateur>   # méthode userpass
vault login -method=ldap username=<utilisateur>        # méthode LDAP

# AppRole (workloads / CI-CD) — voir Vault#Méthodes d'authentification
vault write auth/approle/login role_id="<role_id>" secret_id="<secret_id>"

vault token lookup   # inspecter le token courant

Cycle de vie des tokens

Création et durée de vie

Un token temporaire, limité dans le temps, reste la méthode recommandée pour réduire la fenêtre d'exposition d'un accès :

vault token create -policy="mon-app"                          # token enfant, avec une politique
vault token create -policy="mon-app" -ttl=1h                  # TTL explicite
vault token create -policy="mon-app" -ttl=15m -renewable=false # non renouvelable
vault token create -policy="mon-app" -use-limit=1              # à usage unique
vault token create -policy="mon-app" -ttl=1h -explicit-max-ttl=4h  # plafond absolu, non dépassable

La réponse contient notamment token (la valeur du jeton), token_accessor (identifiant permettant de retrouver/révoquer le token sans manipuler sa valeur en clair — à privilégier pour l'audit) et token_duration (le TTL effectif).

Renouvellement

vault token renew                          # renouveler le token courant
vault token renew -increment=1h            # avec un incrément souhaité
vault token renew <token>                  # un token spécifique
vault token renew -accessor <accessor>     # via l'accessor

Le renouvellement ne peut jamais dépasser l'explicit-max-ttl du token (ni le max TTL du montage) : une fois ce plafond atteint, le token expire définitivement et il faut en recréer un.

Un periodic token, créé avec -period, échappe à cette limite : il n'a pas de TTL maximal et peut être renouvelé indéfiniment, à condition de l'être au moins une fois par période — un choix adapté aux services de longue durée qui renouvellent eux-mêmes leur token en tâche de fond :

vault token create -policy="mon-app" -period=24h

Tokens orphelins et response wrapping

Par défaut, révoquer un token révoque aussi tous ses enfants ; un token orphelin (privilège élevé requis, sudo) survit à la révocation de son parent :

vault token create -policy="mon-app" -orphan

Le response wrapping encapsule un secret (par exemple un secret_id AppRole) dans un token temporaire à usage unique, pour le transmettre sans jamais exposer la valeur en clair sur le trajet :

vault token create -policy="mon-app" -wrap-ttl=5m
vault unwrap <wrapping_token>

Révocation

vault token revoke <token>                  # révoque le token et, par défaut, ses enfants
vault token revoke -accessor <accessor>     # via l'accessor
vault token revoke -mode=orphan <token>     # garde les enfants orphelins en vie
vault token revoke -self                    # auto-révocation du token courant

Secrets et politiques : l'essentiel

Les moteurs de secrets et la syntaxe des politiques sont détaillés sur Vault ; côté CLI, l'usage courant reste :

vault kv put secret/mon-app/db username=admin password=<mot-de-passe>
vault kv get secret/mon-app/db
vault policy write mon-app mon-app.hcl
vault policy list

Scellement et descellement

Le principe du seal/unseal est expliqué sur Vault ; côté commandes :

vault operator unseal          # à répéter jusqu'au quorum de clés (par défaut 3 sur 5)
vault status                   # vérifier que "Sealed" passe à false

vault operator seal            # scellement manuel d'urgence (token privilégié requis)

En production, l'auto-unseal via un KMS externe (AWS KMS, Azure Key Vault, GCP KMS, ou Transit d'un autre Vault) évite l'intervention manuelle au redémarrage.

Sauvegarde et restauration (snapshots Raft)

Avec le stockage intégré Raft, la sauvegarde/restauration du cluster passe par des snapshots — des opérations sensibles nécessitant un token privilégié (typiquement root ou une politique sudo sur sys/storage/raft/snapshot).

Créer une sauvegarde

vault operator raft snapshot save /backup/vault-$(date +%F).snap

Cette opération doit être exécutée contre le nœud leader actif du cluster Raft. Le snapshot contient les données chiffrées : il reste inexploitable sans les clés d'unseal/de recovery correspondantes, mais doit néanmoins être conservé de façon sécurisée (il reflète l'intégralité de l'état de Vault, secrets compris).

Restaurer une sauvegarde

vault operator raft snapshot restore /backup/vault-<date>.snap

Si la restauration cible un cluster dont les clés de chiffrement diffèrent de celles du snapshot d'origine (cas typique d'une reprise après sinistre vers un nouveau cluster), l'option -force est nécessaire :

vault operator raft snapshot restore -force /backup/vault-<date>.snap

Attention : -force ignore la vérification de cohérence des clés d'auto-unseal/recovery. Après une restauration forcée, Vault peut redemander un descellement avec les clés d'origine du snapshot restauré — à réserver aux procédures de reprise après sinistre maîtrisées, jamais à une restauration de routine.

État du cluster Raft

vault operator raft list-peers          # nœuds du quorum
vault operator raft autopilot state     # santé globale du cluster

Reprise en cas de perte des tokens root

Si tous les tokens root ont été perdus ou révoqués, un nouveau peut être régénéré à partir d'un quorum de clés d'unseal, sans jamais exposer ces clés en clair sur le réseau :

vault operator generate-root -init                         # initialise, fournit un nonce et un OTP
vault operator generate-root -nonce=<nonce>                # chaque détenteur de clé fournit sa part
vault operator generate-root -decode=<encoded_token> -otp=<otp>  # décode le token final avec l'OTP
vault operator generate-root -cancel                        # annule une procédure en cours

Rekey et rotation

vault operator rekey -init -key-shares=5 -key-threshold=3   # régénère les clés d'unseal (procédure interactive)
vault operator rotate                                        # fait tourner la clé de chiffrement interne

Bonnes pratiques

• Préférer des tokens à TTL court, renouvelés à la demande, plutôt que des tokens de longue durée.
• Utiliser les accessors pour l'audit et la révocation plutôt que de manipuler les valeurs de token.
• Ne jamais laisser un token root actif en permanence : le générer à la demande, l'utiliser, le révoquer.
• Automatiser le renouvellement des tokens de service via vault agent ou des periodic tokens plutôt qu'un renouvellement manuel.
• Planifier des snapshots Raft réguliers et tester périodiquement la procédure de restauration — un snapshot jamais restauré en test est une sauvegarde non prouvée.
• Répartir les clés d'unseal/recovery entre plusieurs détenteurs de confiance, ou déléguer à l'auto-unseal.
• Activer et exporter les journaux d'audit (vault audit enable).

Dépannage rapide

Symptôme	Piste
Vault is sealed	Descellez avec vault operator unseal (quorum de clés), ou vérifiez l'auto-unseal.
permission denied	Le token n'a pas la politique requise, ou a expiré : vérifiez avec vault token lookup.
token is not renewable	Token créé avec -renewable=false, ou max-ttl atteint : il faut en recréer un.
missing client token	VAULT_TOKEN non défini ou ~/.vault-token absent : relancez vault login.
Échec de restauration sur les clés	N'utilisez -force qu'en connaissance de cause, ou restaurez avec les clés d'origine du snapshot.

Voir aussi

• Vault — concepts généraux : moteurs de secrets, méthodes d'authentification (dont Kubernetes auth), politiques, licence