📍 Article principal : Vault Associate. Ce tutoriel maîtrise l’authentification applicative Vault via AppRole pour CI/CD et JWT pour Kubernetes — méthodes essentielles pour la production.

L’authentification applicative est l’un des sujets les plus critiques de Vault. Comment une application authentifie-t-elle auprès de Vault sans avoir elle-même un secret durable ? Plusieurs auth methods répondent à cette question. AppRole convient aux pipelines CI/CD et aux applications standalone. JWT/OIDC convient aux pods Kubernetes et aux services modernes. Ce tutoriel détaille les deux méthodes avec exemples concrets, patterns de bootstrap, sécurité opérationnelle.

AppRole pour applications et CI/CD

AppRole est l’auth method historique de Vault pour les applications. Le concept : deux secrets distincts (role_id et secret_id) qui ensemble génèrent un token Vault. Le role_id est statique et peut être stocké dans la configuration de l’application. Le secret_id est dynamique avec TTL court — généré à la demande, valide quelques minutes.

Pattern recommandé : la CI génère le secret_id juste avant de le donner au pipeline qui s’authentifie immédiatement et l’utilise. Le secret_id expire avant qu’il ne puisse être réutilisé. Cette ségrégation entre role_id (durable, public) et secret_id (court, privé) prévient les fuites — un attaquant qui obtient role_id sans secret_id ne peut rien faire.

Activation : vault auth enable approle. Création d’un rôle : vault write auth/approle/role/ci-pipeline policies=ci-policy token_ttl=1h secret_id_ttl=10m. Récupération du role_id : vault read auth/approle/role/ci-pipeline/role-id. Génération du secret_id à la demande dans la CI : vault write -f auth/approle/role/ci-pipeline/secret-id. Login dans le pipeline : vault write auth/approle/login role_id=<ID> secret_id=<SECRET>.

JWT/OIDC pour Kubernetes

Pour les pods Kubernetes, JWT/OIDC est l’auth method moderne. Chaque pod Kubernetes reçoit automatiquement un ServiceAccount token qui est un JWT signé par Kubernetes. Vault peut valider ce JWT en consultant l’API Kubernetes et délivrer un token Vault correspondant. Aucun secret applicatif à gérer — l’identité est portée par Kubernetes lui-même.

Configuration : vault auth enable jwt. Configurer la connexion à l’API Kubernetes pour validation des JWT. Créer un rôle qui mappe les ServiceAccounts Kubernetes aux policies Vault. Le pod fait alors un login simple avec son JWT auto-injecté, reçoit un token Vault avec les bonnes permissions, accède aux secrets nécessaires. Ce pattern est devenu le standard cloud-native moderne et constitue le sujet le plus testé sur la Vault Associate côté auth methods.

Comparaison des auth methods

Six auth methods principales à connaître pour la certification. AppRole pour applications standalone et CI. JWT/OIDC pour Kubernetes et services modernes. AWS auth pour applications EC2/Lambda authentifiées par leur identité IAM. Azure auth équivalent pour Azure AD. GCP auth pour GCE et Cloud Functions. LDAP pour intégration avec Active Directory ou OpenLDAP. Token simple pour bootstrap initial.

La règle de décision pour les PME ouest-africaines : AppRole pour le 80 % des cas (CI, applications classiques), JWT pour Kubernetes, LDAP si une infrastructure Active Directory existe déjà. Les auth cloud (AWS, Azure, GCP) sont activées uniquement quand l’application tourne effectivement sur le cloud concerné. Cette approche pragmatique couvre tous les besoins sans complexifier inutilement.

Sécurité opérationnelle des credentials

Quelques disciplines essentielles. Premier : ne jamais committer le role_id ET le secret_id ensemble dans Git. Le role_id peut être versionné dans la configuration applicative, le secret_id doit être généré à la volée par la CI. Deuxième : TTL courts pour limiter les fenêtres d’exploitation — token_ttl 1 heure max, secret_id_ttl 10 minutes max. Troisième : surveillance via audit logs des appels d’authentification — pic anormal de logins échoués signale potentiellement une attaque.

Pour les déploiements à fort enjeu, configurer la rotation périodique automatique des role_id eux-mêmes via les commandes Vault. Cette rotation invalide tous les anciens role_id et force le redéploiement des configurations applicatives — opération à planifier soigneusement mais qui constitue le summum de l’hygiène sécuritaire. La majorité des PME se contentent de TTL courts sans rotation des role_id, ce qui reste largement suffisant pour les enjeux standards.

Cas concret : pipeline CI/CD

Pour ancrer concrètement, voici l’intégration AppRole dans un pipeline GitLab CI. Étape 1, le repo applicatif contient le role_id en variable d’environnement chiffrée. Étape 2, au démarrage du job CI, un script appelle un service « vault-secret-id-generator » auto-hébergé qui authentifie le job (via OIDC GitLab) et génère un secret_id frais. Étape 3, le job s’authentifie auprès de Vault avec role_id + secret_id, récupère un token Vault, lit les secrets nécessaires (clés AWS, mots de passe DB, API keys Mobile Money), exécute le déploiement.

Cette architecture sépare proprement les rôles. La CI a accès uniquement à ce dont elle a besoin (par exemple secrets de production seulement sur la branche main). Les développeurs ne voient jamais les secrets de production directement. L’audit Vault enregistre chaque accès avec l’identité GitLab du job déclencheur — traçabilité complète exploitable lors des audits de conformité.

Mise en œuvre dans le contexte sénégalais

Pour les PME ouest-africaines qui démarrent leur stack DevOps, héberger Vault et la CI sur la même infrastructure simplifie le bootstrap. Hostinger Cloud VPS propose des plans accessibles avec panneau d’administration en français qui facilitent ces déploiements pour les apprenants débutants. Pour les organisations qui se conforment aux exigences de souveraineté, basculer ensuite sur des hébergeurs locaux (Sonatel Datacenter (Sénégal), Liquid Telecom) au moment du passage en production.

Erreurs fréquentes

Erreur	Cause	Solution
secret_id versionné dans Git	Confusion role_id vs secret_id	Seul role_id versionnable, secret_id généré à la volée par CI
JWT non validé par Vault	Connexion API Kubernetes mal configurée	Vérifier kubernetes_host et kubernetes_ca_cert
TTL trop longs	Mauvaises valeurs par défaut	token_ttl 1h max, secret_id_ttl 10min max
Audit logs ignorés	Pas de surveillance des logins	Alertes Prometheus sur taux d’échec auth

Sur un angle proche

🔝 Retour à l’article principal : Vault Associate. Tutoriels précédents : déploiement HA, dynamic secrets. Documentation auth methods : developer.hashicorp.com/vault/docs/auth.

La maîtrise des auth methods constitue le socle de la sécurité Vault. Pour les apprenants ouest-africains qui passent la certification, investir dans la pratique réelle d’AppRole et JWT sur cluster d’entraînement transforme la théorie en aisance opérationnelle attendue par l’examen. Cette discipline pratique est ce qui distingue les candidats qui réussissent à la première tentative des autres.

Un hébergeur abordable pour vos projets

Hostinger combine prix raisonnable et stabilité. Lien partenaire — pas de surcoût pour vous.

Choisir une offre →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Étape 1 — Comprendre AppRole et JWT en 90 secondes

HashiCorp Vault propose deux méthodes d’authentification adaptées aux applications : AppRole (paire role_id + secret_id, modèle pull) et JWT/OIDC (jeton signé par un IdP de confiance, modèle push). AppRole convient aux scripts long-running et workers internes ; JWT convient aux pipelines CI/CD (GitHub Actions, GitLab CI), aux fonctions serverless et aux pods Kubernetes.

APPROLE → 2 secrets (role_id + secret_id) à injecter
JWT/OIDC → 1 jeton court signé par un IdP (GitHub, GitLab, EKS)
DUREE TYPIQUE TOKEN : 1h (renouvelable)
ROTATION SECRET_ID : 24h à 7j max

Le test concluant : vous savez après cette étape laquelle des deux méthodes activer pour votre cas d’usage. Pas besoin de choisir « les deux » au départ.

Étape 2 — Préparer un Vault de test local en 5 minutes

Avant de toucher la production, montez un Vault local en mode dev. Cette commande lance un serveur en mémoire avec un root token affiché dans le terminal — strictement réservé au lab.

vault server -dev -dev-root-token-id="root"
# dans un autre terminal
export VAULT_ADDR="http://127.0.0.1:8200"
export VAULT_TOKEN="root"
vault status

Sortie attendue : Sealed: false et Version: 1.20.x (Vault 1.20 OSS, latest stable mai 2026 — Vault 1.20 LTS atteignait son EOL août 2025). Pour la production, basez-vous sur 1.20 selon votre fenêtre de support. Ne jamais utiliser le mode dev au-delà du lab.

Étape 3 — Activer la méthode AppRole et créer une policy

AppRole se branche en deux commandes. Avant d’attacher un rôle, créez une policy minimale qui décrit ce que l’application a le droit de lire ou écrire. Le principe de moindre privilège s’applique : pas de wildcard * en production.

vault auth enable approle

cat > api-policy.hcl <<EOF
path "secret/data/app/api/*" {
  capabilities = ["read"]
}
EOF
vault policy write api-policy api-policy.hcl

Résultat type : Success! Uploaded policy: api-policy. Vérifiez avec vault policy read api-policy que le contenu est conforme. Une policy mal écrite donne souvent un accès trop large — relisez chaque path.

Étape 4 — Créer le rôle AppRole et récupérer les identifiants

Le rôle AppRole définit la durée de vie du token, le nombre d’utilisations du secret_id et la liste des CIDR autorisés. Verrouillez ces paramètres dès la création.

vault write auth/approle/role/api-worker \
  token_policies="api-policy" \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_ttl=24h \
  secret_id_num_uses=10 \
  bind_secret_id=true

vault read auth/approle/role/api-worker/role-id
vault write -f auth/approle/role/api-worker/secret-id

Résultat attendu : un role_id stable (à committer dans la config applicative chiffrée) et un secret_id à transmettre via un canal sécurisé (CI variable masquée, secret manager Kubernetes). Ne loggez jamais le secret_id.

Étape 5 — Authentifier l’application et récupérer un token Vault

L’application échange role_id + secret_id contre un token Vault à courte durée de vie. Voici l’appel REST minimal en Bash, transposable en Python ou Go.

curl -s --request POST \
  --data '{"role_id":"'"$ROLE_ID"'","secret_id":"'"$SECRET_ID"'"}' \
  $VAULT_ADDR/v1/auth/approle/login \
  | jq -r '.auth.client_token'

Résultat attendu : un token de type hvs.CAESI... valide 1 heure. Stockez-le en mémoire uniquement, jamais sur disque. Renouvelez avec vault token renew avant expiration ou re-loguez-vous.

Étape 6 — Activer la méthode JWT pour GitHub Actions

Pour un pipeline CI, JWT/OIDC élimine la gestion d’un secret_id long. GitHub Actions émet un jeton OIDC pour chaque job, signé par token.actions.githubusercontent.com. Vault le vérifie et émet un token applicatif.

vault auth enable jwt

vault write auth/jwt/config \
  oidc_discovery_url="https://token.actions.githubusercontent.com" \
  bound_issuer="https://token.actions.githubusercontent.com"

vault write auth/jwt/role/github-deploy \
  role_type="jwt" \
  bound_audiences="https://github.com/votre-org" \
  bound_claims_type="glob" \
  bound_claims='{"repository":"votre-org/votre-repo","ref":"refs/heads/main"}' \
  user_claim="actor" \
  policies="api-policy" \
  ttl=20m

Sortie attendue : Success! Data written to: auth/jwt/role/github-deploy. Le bind sur la branche main empêche un pull request d’obtenir un token de prod.

Étape 7 — Consommer le JWT depuis un workflow GitHub Actions

Le job demande un jeton OIDC à GitHub puis l’échange contre un token Vault. Pas de secret long terme stocké côté GitHub.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: hashicorp/vault-action@v3
        with:
          url: https://vault.exemple.sn
          method: jwt
          role: github-deploy
          secrets: |
            secret/data/app/api/* token | API_TOKEN ;

Ce que vous devez voir : la variable API_TOKEN est exposée au step suivant, masquée dans les logs. Si le job échoue avec permission denied, vérifiez les bound_claims côté Vault et la branche déclenchante.

Étape 8 — Auditer et faire tourner les secrets

Activez l’audit dès la mise en production. Toute opération est tracée dans un fichier append-only que vous expédiez vers un SIEM (Wazuh, Elastic). Pour AppRole, programmez la rotation du secret_id toutes les 24 heures via un job CI dédié. Pour JWT, aucune rotation manuelle nécessaire — le jeton est éphémère par nature.

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

# rotation secret_id (cron quotidien)
vault write -f auth/approle/role/api-worker/secret-id \
  | jq -r '.data.secret_id' > /run/secrets/api_secret_id

Ce que vous devez voir : un fichier d’audit qui grossit, à compresser et expédier hors du serveur Vault. Pour creuser ce sujet sur la mise en production souveraine en Afrique de l’Ouest, voir notre tutoriel installation Vault production et notre guide sécuriser une application web déployée au Sénégal.

Étape 9 — Intégrer Vault dans une application Python

La bibliothèque hvac couvre AppRole et JWT en quelques lignes. Installez-la dans un virtualenv dédié, puis chargez les identifiants depuis l’environnement — jamais en dur dans le code source committé.

pip install hvac==2.3.0

import os, hvac
client = hvac.Client(url=os.environ["VAULT_ADDR"])
client.auth.approle.login(
    role_id=os.environ["VAULT_ROLE_ID"],
    secret_id=os.environ["VAULT_SECRET_ID"],
)
secret = client.secrets.kv.v2.read_secret_version(
    path="app/api/db", mount_point="secret",
)
db_password = secret["data"]["data"]["password"]

Résultat attendu : db_password contient la valeur stockée dans Vault sans qu’aucun secret transite par votre dépôt Git. Encadrez l’appel par un try/except hvac.exceptions.InvalidPath pour gérer une rotation pendant l’exécution.

Étape 10 — Diagnostiquer les erreurs courantes

Trois erreurs reviennent en production. Premièrement permission denied — la policy ne couvre pas le path demandé, vérifiez avec vault token capabilities $TOKEN secret/data/app/api/db. Deuxièmement invalid secret_id — le secret_id a expiré ou atteint son quota d’utilisations, regénérez-le. Troisièmement oidc: id token verification failed sur JWT — l’horloge du runner est désynchronisée, installez chrony ou systemd-timesyncd.

# vérifier les capabilities du token
vault token capabilities $TOKEN secret/data/app/api/db

# inspecter un secret_id
vault write auth/approle/role/api-worker/secret-id-accessor/lookup \
  secret_id_accessor=$ACCESSOR

Ce que vous devez voir : la commande capabilities renvoie read si la policy est correcte. Toute autre réponse indique un trou dans la policy à boucher avant la mise en service.

Étape 11 — Choisir entre AppRole et JWT selon le contexte ouest-africain

En contexte de déploiement à Dakar, Abidjan ou Lomé, deux paramètres orientent le choix : la connectivité réseau et l’IdP disponible. Si l’application tourne sur un VPS isolé sans intégration GitHub Actions ni Kubernetes, AppRole reste le choix simple. Si vous opérez déjà une CI GitHub ou GitLab et que vos workers tournent sur EKS, GKE ou un cluster Kubernetes managé chez un hébergeur africain, JWT/OIDC supprime la gestion d’un secret_id long terme et réduit la surface d’attaque.

Pour une équipe de moins de 5 personnes, commencez par AppRole, observez 2 à 3 mois en production avec audit log activé, puis migrez vers JWT au fur et à mesure que la CI prend de l’ampleur. Documentez chaque rôle créé dans un README interne avec son owner, sa policy et sa rotation.