🔐 HashiCorp Vault – Secrets Management & Encryption

Tokens & AppRole

                        # Auth method AppRole
                        vault auth enable approle

                        vault write auth/approle/role/django \
                        token_policies="django-app" \
                        token_ttl="1h" \
                        token_max_ttl="24h"

                        # Récupérer role_id & secret_id
                        vault read auth/approle/role/django/role-id
                        vault write -f auth/approle/role/django/secret-id
                    

Une app peut s’authentifier avec (role_id, secret_id) pour obtenir son token Vault.

Kubernetes & OIDC

• Kubernetes : Vault valide le JWT du ServiceAccount.
• OIDC : intégration avec un IdP (Keycloak, Azure AD…).
• LDAP/GitHub : pour les utilisateurs humains.

                        vault auth enable kubernetes

                        vault write auth/kubernetes/config \
                        kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
                        token_reviewer_jwt="$SA_JWT" \
                        kubernetes_ca_cert="$SA_CA_CRT"
                    

Integrated Storage (Raft)

Mode recommandé pour de nombreuses installs : pas besoin d’un système externe (Consul).

                        storage "raft" {
                        path    = "/opt/vault/data"
                        node_id = "vault-1"
                        }
                    

• HA natif (plusieurs nodes Raft).
• Snapshot & backup via commandes Raft.

Consul & autres backends

Quel que soit le backend, les données sont déjà chiffrées par Vault avant d’être écrites dans le storage.

Policy HCL

                        # django-app.hcl
                        path "secret/data/app/django/*" {
                        capabilities = ["read", "list"]
                        }

                        path "database/creds/django-role" {
                        capabilities = ["read"]
                        }
                    

                        vault policy write django-app django-app.hcl
                    

Tokens liés aux policies

                        vault token create -policy="django-app" -ttl="1h"

                        # voir les infos
                        vault token lookup <token>
                    

• Principe du least privilege : chaque app a sa policy minimale.
• TTL court sur les tokens (et possibilité de renewal contrôlé).
• Pas de partage de token entre apps/services.

Pattern “Vault Agent + Template”

                        # agent.hcl
                        exit_after_auth = false
                        pid_file = "/run/vault-agent.pid"

                        auto_auth {
                        method "approle" {
                        mount_path = "auth/approle"
                        config = {
                        role_id_file_path   = "/etc/vault/role_id"
                        secret_id_file_path = "/etc/vault/secret_id"
                        }
                        }

                        sink "file" {
                        config = {
                        path = "/run/vault/token"
                        }
                        }
                        }

                        template {
                        source      = "/etc/vault/templates/django.env.tpl"
                        destination = "/run/vault/django.env"
                        }
                    

Template d’env (extrait)

                        
                        DJANGO_SECRET_KEY="{{ with secret "secret/data/app/django" -}}
                        {{ .Data.data.DJANGO_SECRET_KEY }}{{- end }}"
                        DB_PASSWORD="{{ with secret "secret/data/app/django" -}}
                        {{ .Data.data.DB_PASSWORD }}{{- end }}"
                        
                    

L’app source simplement /run/vault/django.env au démarrage ; Vault Agent gère toute la complexité (auth, rotation, templates…).

Base de données

                        # obtenir un user DB dynamique
                        vault read database/creds/django-role

                        Key                Value
                        ---                -----
                        lease_id           database/creds/django-role/...
                        lease_duration     1h
                        lease_renewable    true
                        username           v-token-django-1234
                        password           A1b2C3d4...
                    

• TTL court (ex: 1h), renouvelable si besoin.
• Révocation automatique à la fin du lease.

Cloud credentials (AWS par ex.)

                        vault secrets enable aws

                        vault write aws/config/root \
                        access_key="AKIA..." \
                        secret_key="..." \
                        region="eu-west-1"

                        vault write aws/roles/app-role \
                        credential_type=iam_user \
                        policy_document=@policy.json

                        vault read aws/creds/app-role
                    

Tes apps n’utilisent plus de access keys “permanentes” ; Vault émet des credentials à durée de vie limitée, avec des permissions minimales.

GitHub Actions (exemple)

                        name: Build & Deploy

                        on:
                        push:
                        branches: [ main ]

                        jobs:
                        deploy:
                        runs-on: ubuntu-latest
                        steps:
                        - uses: actions/checkout@v4

                        - name: Install Vault CLI
                        run: |
                        sudo apt-get update && sudo apt-get install -y vault

                        - name: Fetch secrets from Vault
                        env:
                        VAULT_ADDR: $
                        VAULT_TOKEN: $
                        run: |
                        vault kv get -format=json secret/app/django \
                        | jq -r '.data.data.DJANGO_SECRET_KEY' \
                        >> $GITHUB_ENV
                    

Bonnes pratiques CI/CD

• Le pipeline CI s’authentifie lui-même via un AppRole dédié.
• Les secrets ne sont jamais commités ni stockés dans les logs.
• TTL très courts pour les tokens CI.
• Audit activé pour suivre les lectures de secrets par les pipelines.

Initialisation & Unseal

                        vault operator init

                        Unseal Key 1: xxx
                        Unseal Key 2: yyy
                        Unseal Key 3: zzz
                        Initial Root Token: s.xxxxx
                    

• Les unseal keys sont réparties (Shamir) entre plusieurs personnes.
• Plusieurs keys sont nécessaires pour “ouvrir” Vault après un restart.
• Le root token ne doit servir qu’à la bootstrap, puis être révoqué.

Hardening réseau & TLS

• Vault toujours derrière TLS (certs valides, pas de TLS disable).
• Accès réseau très restreint (SG, firewall, mTLS éventuellement).
• Audit logs activés sur un backend (fichier, syslog, SIEM).

                        vault audit enable file file_path=/var/log/vault/audit.log
                    

Monitoring

• Exporter les métriques vers Prometheus / Grafana.
• Surveiller le leader HA, la latence API, les erreurs.
• Alertes sur les errors d’auth, les 5xx API, etc.

                        # Exemple : endpoint /sys/metrics (selon version/licence)
                        curl $VAULT_ADDR/v1/sys/health
                    

Sauvegardes & DRP

• Avec Raft : snapshots réguliers du storage data.
• Test de restore régulier (environnement de DRp).
• Documenter la procédure de re-unseal en DR (quorum de personnes).

L’objectif : capacité à reconstruire un cluster Vault fonctionnel à partir des snapshots + des unseal keys, dans un délai maîtrisé (RTO).

CLI essentiel

                        vault status                     # état du cluster
                        vault login                      # login interactif
                        vault kv put/get                 # secrets KV
                        vault token create               # créer un token
                        vault token revoke               # révoquer
                        vault policy list/read/write     # policies
                        vault auth enable/disable        # auth methods
                        vault secrets enable/disable     # engines
                        vault operator init/unseal       # Bootstrap
                        vault operator rekey/rotate      # Gestion clés
                    

Patterns à retenir

• Jamais de secrets en clair dans Git : tout passe par Vault.
• Utiliser des policies dédiées aux apps & teams.
• TTL court partout (tokens, dynamic secrets, leases).
• Vault Agent/sidecar quand c’est possible, plutôt que d’embarquer un client lourd dans l’app.
• Activer & monitorer l’audit en continu.