Vault sur les trois clouds : secrets engines, dynamic credentials et intégration avec Kubernetes

HashiCorp Vault est la référence pour la gestion centralisée des secrets, qu’il s’agisse de mots de passe, clés API, certificats ou tokens. En environnement multi-cloud (AWS, Azure, GCP) et Kubernetes, Vault permet d’éliminer les secrets en dur, de générer des identifiants temporaires (dynamic credentials) et d’automatiser l’injection de secrets dans les pods. Dans cet article, je vous montre comment déployer Vault et l’intégrer efficacement sur les trois grands clouds.

1. Pourquoi Vault plutôt que Secrets Manager natif ?

Chaque cloud a son propre service de secrets (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Mais en environnement multi-cloud, Vault offre une couche d’abstraction unique, des secrets engines pluggables, du leasing, de la rotation automatique et une gestion fine des politiques (policy as code). De plus, son intégration avec Kubernetes est mature et ne vous enferme pas chez un fournisseur.

2. Architecture typique de Vault en multi-cloud

On déploie généralement un cluster Vault (mode HA) sur chaque cloud ou bien un cluster centralisé avec des replicators. Le stockage backend peut être Consul, Raft intégré (Vault 1.10+), ou utiliser des services natifs comme AWS DynamoDB, Azure Cosmos DB, GCP Cloud Spanner. Voici un exemple simple de configuration backend pour AWS :

storage "raft" {
  path = "/vault/data"
  node_id = "node1"
}

ha_storage "raft" {
  path = "/vault/data/raft"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = false
  tls_cert_file = "/vault/config/tls.crt"
  tls_key_file  = "/vault/config/tls.key"
}

3. Secrets engines essentiels pour AWS, Azure, GCP

🔹 AWS Secrets Engine (dynamic credentials)

Permet de générer des clés IAM temporaires (STS) à la demande, avec des permissions granulaires. Exemple d’activation :

vault secrets enable aws
vault write aws/config/root \
  access_key=AKIA... \
  secret_key=...
vault write aws/roles/my-role \
  credential_type=iam_user \
  policy_document='{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:ListBucket","Resource":"*"}]}'
vault read aws/creds/my-role

🔹 Azure Secrets Engine

Génère des tokens Azure AD et des certificats pour les service principals ou les managed identities. Utile pour des pipelines CI/CD multi-cloud.

vault secrets enable azure
vault write azure/config \
  subscription_id=xxx \
  tenant_id=xxx \
  client_id=xxx \
  client_secret=xxx
vault write azure/roles/my-app \
  ttl=1h \
  azure_roles='[{"role_name":"Contributor","scope":"/subscriptions/xxx/resourceGroups/my-rg"}]'
vault read azure/creds/my-app

🔹 GCP Secrets Engine

Génère des comptes de service GCP ou des tokens OAuth2 avec des rôles spécifiques. Idéal pour des workloads éphémères.

vault secrets enable gcp
vault write gcp/config credentials=@sa-key.json
vault write gcp/roleset/my-token \
  project="my-project" \
  secret_type="access_token" \
  token_scopes="https://www.googleapis.com/auth/cloud-platform" \
  bindings='resource "//cloudresourcemanager.googleapis.com/projects/my-project" { roles = ["roles/viewer"] }'
vault read gcp/token/my-token

4. Intégration de Vault avec Kubernetes : deux approches

Pour injecter des secrets dans vos pods sans les stocker dans des Secrets Kubernetes (qui sont souvent en clair en base64), vous avez deux méthodes principales :

✅ 1. Agent Sidecar Injector (Vault Agent)

Un conteneur sidecar (vault-agent) tourne aux côtés de votre application. Il s’authentifie auprès de Vault (via Kubernetes auth method), récupère les secrets dynamiques et les écrit dans un volume partagé. Votre application lit simplement un fichier local. Exemple d’annotation sur un deployment :

annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "my-app-role"
  vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/my-app"

✅ 2. CSI Driver (Container Storage Interface)

Permet de monter des secrets Vault directement comme un volume via le driver secrets-store.csi.k8s.io. Les secrets sont synchronisés périodiquement. C’est plus léger qu’un sidecar, mais moins dynamique pour les changements à la volée.

kind: Pod
spec:
  containers:
  - name: app
    volumeMounts:
    - name: secrets-store
      mountPath: "/mnt/secrets"
  volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: "vault-database"

5. Authentification Kubernetes (Auth Method)

Pour que Vault fasse confiance à vos pods, on configure l’auth method Kubernetes. Chaque pod a un service account token (JWT) que Vault valide contre l’API Kubernetes. Exemple de configuration :

vault auth enable kubernetes
vault write auth/kubernetes/config \
  kubernetes_host="https://$KUBE_HOST" \
  kubernetes_ca_cert=@ca.crt
vault write auth/kubernetes/role/my-app-role \
  bound_service_account_names=my-sa \
  bound_service_account_namespaces=default \
  policies=my-policy \
  ttl=24h

6. Gestion des leases et rotation automatique

Vault ne stocke pas les secrets statiquement ; il génère des credentials avec une durée de vie (lease). Vous pouvez également déclencher des rotations automatiques via vault lease renew ou des controllers comme vault-crd. En production, nous utilisons Vault’s database secrets engine pour gérer les mots de passe de bases de données PostgreSQL, MySQL, etc. avec rotation périodique.

7. Bonnes pratiques pour Vault en production

• Haute disponibilité : déployez au moins 3 nœuds Vault avec backend Raft ou Consul.
• Chiffrement des métadonnées : activez le seal auto-déverrouillage (KMS seal) avec AWS KMS, Azure Key Vault ou GCP Cloud KMS.
• Politiques (policies) : appliquez le moindre privilège, chaque application ne doit avoir accès qu’à son propre chemin de secrets.
• Audit logging : activez les device logs vers un stockage immuable (S3, GCS, Azure Blob).
• Réplication : utilisez vault replication (perf/secondary) pour des architectures multi-régions ou multi-cloud.

8. Exemple complet : Intégration d’une app Node.js avec Vault sur AKS (Azure)

L’application lit un secret dynamique PostgreSQL depuis Vault via le sidecar :

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-postgres
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "app-postgres"
        vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/app-role"
        vault.hashicorp.com/agent-inject-template-db-creds: |
          {{ with secret "database/creds/app-role" -}}
          POSTGRES_USER={{ .Data.username }}
          POSTGRES_PASSWORD={{ .Data.password }}
          {{- end }}
    spec:
      serviceAccountName: vault-auth
      containers:
        - name: app
          image: myapp:latest
          env:
            - name: DB_HOST
              value: "postgres.example.com"
          volumeMounts:
            - name: vault-secrets
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: vault-secrets
          emptyDir:
            medium: Memory

Le fichier /etc/secrets/db-creds contient les variables d’environnement attendues, que l’application peut charger avec dotenv. Pas de secret dans le pod, pas de stockage en base64.

Conclusion

Vault est un outil incontournable dès que vous sortez d’un cloud unique ou que vous avez des exigences élevées de sécurité. Il élimine les secrets en clair des code repositories, automatise la rotation et s’intègre nativement à Kubernetes. Lancez-vous avec le mode dev pour tester, puis passez en production avec un KMS seal et des politiques restrictives.

Prochain article : je vous montrerai comment automatiser le déploiement de Vault avec Terraform sur les trois clouds, avec un backtend Raft et un équilibrage de charge.