Aller au contenu principal
TechLedger Registre technique
devopsvault

HashiCorp Vault Server standalone et HA, Secrets engines, authentication methods, intégration de vault injector et Vault Secret Operator VSO

HashiCorp Vault de bout en bout : monter un serveur qui survit à son redémarrage, choisir un stockage en sachant ce qu'il interdit, faire fabriquer des comptes de base de données qui meurent seuls en 2 minutes, et amener ces secrets dans 2 clusters Kubernetes par les 2 chemins concurrents, Vault Agent Injector et Vault Secrets Operator, comparés sur le même secret, mesures à l'appui.

coolibra12 sept. 20261929 vues

Ce que vous saurez faire

  1. Installer Vault de 3 façons (Docker Compose, standalone sur Kubernetes, 3 réplicas en haute disponibilité) et savoir laquelle convient à quoi.
  2. Choisir un backend de stockage en connaissant ce qu'il interdit : s3 ne fait pas de haute disponibilité, gcs et raft si.
  3. Faire desceller Vault tout seul au redémarrage, et savoir ce que ce montage déplace plutôt qu'il ne supprime.
  4. Ranger des secrets dans KV v2, s'en servir de l'historique, et écrire la policy qui va avec : celle dont le chemin n'est pas celui qu'on croit.
  5. Faire fabriquer par Vault des comptes PostgreSQL à la demande, qui existent 2 minutes et que Vault supprime lui-même.
  6. Chiffrer des données applicatives sans que la clé sorte jamais de Vault, et faire tourner cette clé sans réécrire une ligne en base.
  7. Authentifier un cluster Kubernetes auprès d'un Vault qui tourne ailleurs, sans distribuer le moindre secret.
  8. Servir une application par Vault Agent Injector : un fichier écrit dans le pod, l'application inchangée.
  9. Servir un cluster par Vault Secrets Operator : des Secret Kubernetes ordinaires, et le redémarrage automatique des applications qui ne savent pas relire.
  10. Décrire la structure d'un Vault en Terraform, en sachant précisément où s'arrêter.

Comment cette formation est faite

Chaque commande publiée ici a été exécutée, et chaque sortie de terminal est réelle. Les versions aussi ont été vérifiées auprès de la source qui fait autorité (dépôt de charts, registre de paquets, documentation officielle) plutôt que citées de mémoire.

Quand une chose ne marche pas, la formation le dit. Un nc -z qui échoue et ne prouve rien, un cap_add: IPC_LOCK qui ne suffit pas, un helm upgrade qui ne redéploie rien : ces trois-là ont été rencontrés en écrivant les chapitres, et ils y sont.

Et quand une chose n'a pas été exécutée, la formation le dit aussi. Une seule section est dans ce cas (la configuration d'un backend Google Cloud Storage et de son KMS, faute de compte cloud) et elle le signale à l'endroit où elle s'applique.

Le lab, monté sur 2 clusters

Deux clusters Kubernetes v1.36.4, et ce n'est pas un luxe.

Le premier porte les serveurs : un MinIO qui tient lieu de stockage objet compatible S3, un Vault sur ce backend, un Vault sur backend fichier qui fait office de KMS, et un Vault en haute disponibilité à 3 réplicas en stockage intégré raft, qui se descelle tout seul par le moteur transit du précédent.

Le second porte les clients : le Vault Agent Injector, le Vault Secrets Operator, et l'application témoin.

Les avoir séparés change tout. Un Vault installé dans le namespace voisin de ses clients masque entièrement les difficultés réelles : l'accès réseau, l'authentification d'un cluster par un serveur qui n'est pas dedans, et un trio d'obstacles TLS qui se masquent l'un l'autre et coûtent une demi-journée à qui ne les a jamais vus. Ici, tout cela est traité de front.

Ce que la formation mesure

Les chiffres ne sont pas repris d'une documentation, ils sortent du lab :

  • un compte PostgreSQL fabriqué à la demande, bail de 120 secondes, supprimé par Vault après 115 secondes sans que personne n'intervienne ;
  • une rotation dans Vault qui atteint le fichier d'un pod servi par l'injector en ~5 minutes : le défaut de static_secret_render_interval, et non une lenteur ;
  • la même rotation qui atteint un Secret Kubernetes par VSO en 24 secondes ;
  • et une application incapable de relire son secret, redémarrée en 51 secondes, redémarrage compris.

C'est sur ces mesures que le dernier module tranche la question que le titre pose : injector ou VSO. La réponse tient en une ligne, et elle n'est pas « l'un des deux ».

Le fil rouge

Escale, une plateforme de réservation de voyages prise comme hypothèse de travail. Son API a besoin des identifiants de sa base PostgreSQL, et chaque module ajoute une exigence de production à ce montage : d'abord un serveur qui tient, puis des secrets qui meurent seuls, puis une authentification qui ne distribue rien, puis 2 façons d'amener tout cela dans un cluster.

Prérequis

Kubernetes au niveau du quotidien : Pod, Deployment, Secret, namespace, RBAC, et l'usage courant de kubectl. Des notions de Helm. La ligne de commande Linux ou macOS.

Aucune connaissance de Vault n'est supposée : le module 01 part du problème.

Chapitres