chef-vault : chiffrer un secret pour les seuls nœuds autorisés

Logo Chef

Les data bags chiffrés ont un défaut structurel : une seule clé déchiffre tout. Le serveur web qui la possède peut lire les secrets de la base de données. chef-vault supprime cette faiblesse : il chiffre chaque secret pour les clés publiques des nœuds autorisés, individuellement. Aucune clé partagée à distribuer, et une révocation immédiate. Public visé : avancés disposant d'un serveur CINC.

Ce que vous allez apprendre

Comprendre ce que chef-vault change par rapport à la clé partagée.
Chiffrer un secret pour un ensemble de nœuds.
Consommer le secret dans une recette.
Révoquer l'accès d'un nœud.

Prérequis

Un serveur CINC avec au moins un nœud enrôlé.
Les data bags chiffrés, dont chef-vault corrige la limite.

Le problème que chef-vault résout

Avec un data bag chiffré classique, vous déployez le même fichier secret sur tous les nœuds. Conséquence directe : tout nœud qui l'a peut tout déchiffrer, y compris ce qui ne le concerne pas. Ajouter une machine, c'est élargir la surface. Retirer une machine, c'est devoir changer la clé partout.

chef-vault renverse la logique. Chaque nœud possède déjà une paire de clés, créée lors de son enrôlement : c'est son identité auprès du serveur. chef-vault s'en sert. Il chiffre le secret une fois avec une clé de session, puis chiffre cette clé de session séparément pour la clé publique de chaque autorisé.

Résultat : rien à distribuer. Le nœud déchiffre avec la clé qu'il possède déjà, et lui seul.

Créer un coffre

La commande knife vault create chiffre le secret et désigne les autorisés. Les nœuds sont sélectionnés par une recherche, pas par une liste figée :

knife vault create coffres bdd \
  '{"user":"appuser","password":"S3cr3t-Vault-2026"}' \
  --search 'recipes:webstack*' \
  --admins stephane \
  --mode client

Le --search est le cœur du mécanisme : « tous les nœuds portant la recette webstack » sont autorisés. Les --admins sont les humains qui pourront relire et modifier le secret.

Regarder ce que le serveur stocke réellement

C'est en ouvrant le capot qu'on comprend. chef-vault crée deux éléments.

Le premier, bdd, contient le contenu chiffré en aes-256-gcm. Sans clé, il est illisible :

knife data bag show coffres bdd

id:       bdd
password:
  cipher:         aes-256-gcm
  encrypted_data: 8JqCSvFO9YVFW2rMF8fFU9DZGFAxXUL+CLViGjrn5PKfxecH

Le second, bdd_keys, est la pièce maîtresse. Il liste qui est autorisé, et contient pour chacun la clé de session rechiffrée avec sa clé publique :

knife data bag show coffres bdd_keys

admins:       stephane
clients:      web-srv1
search_query: recipes:webstack*
stephane:     idt5bTvYU2gw2BjPEfhWK4l4BcVW4QqKbeK1610Gkcaf2gD+lx18ZG2B...
web-srv1:     NjNIcck4mAiddoU8gL2n28jlAXka3PAi3wiParp4raWcp9RmYEP57p+Z...

Deux entrées, deux chiffrements distincts du même secret de session. C'est exactement ce que la clé partagée ne savait pas faire.

Consommer le secret dans une recette

Côté recette, rien de compliqué : on charge l'élément de coffre. Le nœud utilise sa clé client pour le déchiffrer, sans qu'aucun fichier secret ne lui ait été transmis.

creds = ChefVault::Item.load('coffres', 'bdd')

file '/etc/appdb/vault.yml' do
  owner   'root'
  group   'root'
  mode    '0600'
  sensitive true
  content <<~CONF
    username: #{creds['user']}
    password: #{creds['password']}
  CONF
end

À la convergence, le fichier apparaît, en 0600, avec le secret déchiffré :

sudo cinc-client
sudo cat /etc/appdb/vault.yml

Recipe: vaultdemo::default
  * file[/etc/appdb/vault.yml] action create
    - create new file /etc/appdb/vault.yml

username: appuser
password: S3cr3t-Vault-2026

L'attribut sensitive true reste indispensable : sans lui, Chef afficherait le contenu du fichier dans la sortie de convergence, donc dans les logs.

Révoquer un accès, pour de vrai

C'est ici que chef-vault se distingue de façon décisive. Retirons le nœud des autorisés :

knife vault remove coffres bdd --clients web-srv1 --mode client

L'item de clés ne contient plus aucun client :

admins:       stephane
clients:

À la convergence suivante, le nœud ne peut plus déchiffrer, et il le dit clairement :

FATAL: ChefVault::Exceptions::SecretDecryption:
coffres/bdd is not encrypted with your public key.
Contact an administrator of the vault item to encrypt for you!

Aucune intervention sur la machine n'a été nécessaire. Avec une clé partagée, révoquer un nœud aurait supposé de changer la clé, puis de la redistribuer à tous les autres. Ici, on retire une entrée, et c'est fini.

Le revers de la médaille : un nœud qui rejoint le parc après la création du coffre n'est pas automatiquement autorisé, même s'il correspond à la recherche. Il faut rafraîchir le coffre pour qu'il rechiffre vers les autorisés courants :

knife vault update coffres bdd --search 'recipes:webstack*' --mode client

Oublier cette étape est la cause numéro un des SecretDecryption sur une machine fraîchement enrôlée. Intégrez-la à votre procédure de mise en service.

Après rafraîchissement, le nœud figure de nouveau parmi les autorisés et la convergence repasse au vert.

Dépannage

Les erreurs de chef-vault tournent presque toutes autour d'une même question : ce nœud est-il autorisé ? Voici comment les lire.

Symptôme	Cause probable	Solution
`SecretDecryption: not encrypted with your public key`	Le nœud n'est pas (ou plus) autorisé	`knife vault update ... --search ...` pour rechiffrer
Un nœud fraîchement enrôlé ne déchiffre pas	Le coffre n'a pas été rafraîchi depuis son arrivée	Même correction : `knife vault update`
`knife vault` indisponible	chef-vault absent de l'outillage	Il est fourni avec CINC Workstation
Le secret apparaît dans les logs	`sensitive true` oublié	L'ajouter, puis changer le secret exposé
Impossible d'utiliser chef-vault	Vous êtes en local mode	Le mécanisme exige les clés publiques d'un serveur

À retenir

Le data bag chiffré repose sur une clé partagée : tout nœud qui l'a peut tout déchiffrer.
chef-vault chiffre la clé de session pour la clé publique de chaque autorisé : rien à distribuer.
Les autorisés se désignent par une recherche (--search), pas par une liste figée.
Deux éléments sont créés : le contenu chiffré, et l'item _keys qui dit qui peut lire.
La révocation est immédiate et sans toucher à la machine : le nœud échoue avec SecretDecryption.
Un nœud arrivé après la création du coffre n'est pas autorisé automatiquement : rafraîchir avec knife vault update.
chef-vault exige un serveur : c'est un argument concret pour en monter un.

Pour aller plus loin

Gérer ses secrets : les principes, au-delà de Chef.
HashiCorp Vault : l'étape suivante, avec secrets dynamiques et rotation automatique.