BlueWeave

Introduction Dans mon article sur le Secret Manager d'OVHcloud, j'expliquais que j'évitais OpenBao sur les petits clusters parce que l'héberger est pénible : il faut gérer les volumes (on est pas en stateless) et surtout le unseal. À chaque redémarrage de pod, OpenBao repart scellé et attend qu'on lui présente ses clés. Sur un cluster qu'on recrée le temps d'un live, c'est infernale. Cette étape peut se faire manuellement (avec une ou plusieurs clés) via une puce TSM (sur du hardware spécifique) ou via un autre KMS (pouvant être un Vault/Bao également). Et dans mon précédent article, je montrais le combo External-Secret x OVH KMS pour stocker des secrets. Dans celui-ci, on va voir comment l'utiliser pour unseal automatiquement notre Bao (ce qui est cool aussi, c'est qu'OVH supporte l'API Vault nativement). Commençons déjà par détailler ce que c'est Unseal. C'est quoi l'unseal ? OpenBao chiffre tout ce qu'il stocke avec une root key. Cette root key est elle-même chiffrée, et c'est là que ça se joue : - Seal Shamir (le défaut) : la root key est découpée en parts qu'on distribue à des humains (ou a des scripts). Au démarrage, il faut en ressaisir 3 sur 5 (configurable). Fiable, pénible. - Auto-unseal : la root key est chiffrée par une clé externe détenue par un KMS/TSM. Au démarrage, OpenBao appelle le serveur KMS ou la puce TSM, récupère sa root key en clair et se déverrouille tout seul. Deux voies vers l'OKMS OpenBao propose deux façons de parler à un KMS OVHcloud, et le choix n'est pas anodin. La première est le seal ovhcloud, un plugin externe (kms-ovhcloud), listé par OVHcloud comme l'intégration officielle. Il parle à l'API REST de l'OKMS. La seconde est le seal kmip, natif. Le plugin ovhcloud n'est pas dans l'image : il faut le télécharger depuis ghcr.io avant que le serveur puisse se déverrouiller. Comme je suis pas fan de dépendre sur une autre image, je vais privilégier l'intégration déjà présente. Préparer le KMS Je pars du principe que vous avez déjà un OKMS provisionné (ça se fait depuis la WebUI, comme pour le Secret Manager). Il nous faut deux choses : un certificat client, et une clé qu'on va générer nous-même Le certificat client L'endpoint KMIP n'accepte qu'une seule authentification : le mTLS. Pas de token, pas de PAT. On génère donc une paire de clés localement et on ne fait signer que le CSR — la clé privée ne sort jamais de la machine : Puis on envoie le CSR à l'API OVH, en le rattachant à une identité (ici je fais crado avec l'utilisateur principal mais un utilisateur IAM dédié est plus propre serait propre, je détaille sa création dans l'autre article) : Le certificat signé se récupère ensuite sur GET /v2/okms/resource/d37ae355-8e45-419a-8da2-663e2c7bec12/credential/def89cc7-d353-4709-b8a5-85706c3b28ec via l'API OVH. {{< notice tip >}} à retenir quand même la valeur du champ validity qui plafonne à 365 jours. Notez la date quelque part : le jour où ce certificat expire, OpenBao ne peut plus se déverrouiller et il faudra faire une rotation. {{< /notice >}} La clé de seal Pour créer une clé KMIP, il faut parler KMIP. La CLI d'OVH s'en charge (installée évidemment avec Mise :D) On doit ensuite l'activer, une clé KMIP qui vient d'être créée est en état pre-active et OpenBao refusera de s'en servir. Déployer OpenBao Le certificat client part dans un Secret de type TLS, que l'on montera dans le pod : Puis les values du chart Helm officiel pointant vers ce même secret Puis on peut installer tranquilou notre OpenBao : Dans les logs, on voit qu'il récupère bien la clé via le KMS. Il ne reste qu'à l'initialiser et c'est la seule fois où on aura affaire à des clés : Les unseal_keys sont vides : ce qui veut dire qu'il les récupère bien depuis le KMS. Ce qui reste en local, ce sont les recovery_keys (pour unseal si on perd l'accès au KMS) et le root token (premier token admin) à garder précieusement. On peut faire le test final en supprimant un pod OpenBao pour voir s'il arrive à se unseal de manière autonome seul. Dans les logs du nouveau pod : Une petite seconde pour l'unseal et ça sans intervention.