📍 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é.
Adaptation au contexte ouest-africain
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 (Wagaden Sénégal, Sonatel Cloud) 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 |
Pour aller plus loin
🔝 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.