Vault : authentification userpass et AppRole

Avant d'accéder à un secret dans Vault, un client doit prouver son identité. Vault propose plusieurs méthodes d'authentification selon le contexte : utilisateurs humains, applications, pipelines CI/CD, workloads cloud.

Ce guide couvre les deux méthodes les plus courantes :

• userpass : authentification par identifiant/mot de passe (utilisateurs)
• AppRole : authentification pour applications et CI/CD

Prérequis

Installer Vault Installation et premier démarrage

Policies Comprendre les policies d'accès

• Vault installé et démarré
• Accès admin (root token ou policy admin)

Userpass : pour les utilisateurs humains

La méthode userpass est simple : identifiant + mot de passe. Elle convient aux développeurs qui accèdent à Vault via la CLI ou l'UI.

Activer userpass

vault auth enable userpass

Sortie :

Success! Enabled userpass auth method at: userpass/

Créer un utilisateur

vault write auth/userpass/users/alice \
    password="SecurePassword123!" \
    policies="dev-policy"

Policies

Chaque utilisateur est associé à une ou plusieurs policies qui définissent ses permissions. Consultez le guide Policies.

Se connecter

L'utilisateur alice peut maintenant se connecter :

vault login -method=userpass \
    username=alice \
    password="SecurePassword123!"

Sortie :

Success! You are now authenticated.

Key                    Value
---                    -----
token                  hvs.CAESICpTptPYxzwJISnFYQQRZzz7ftYL...
token_accessor         ORgCVUVANPcCkzgF8oKs9ZRc
token_duration         768h
token_renewable        true
token_policies         ["default" "dev-policy"]
identity_policies      []
policies               ["default" "dev-policy"]
token_meta_username    alice

Le token retourné est automatiquement stocké dans ~/.vault-token pour les commandes suivantes.

Gérer les utilisateurs

# Lister les utilisateurs
vault list auth/userpass/users/

# Modifier le mot de passe
vault write auth/userpass/users/alice password="NewPassword456!"

# Modifier les policies
vault write auth/userpass/users/alice policies="dev-policy,staging-readonly"

# Supprimer un utilisateur
vault delete auth/userpass/users/alice

Configuration du token

Vous pouvez personnaliser la durée de vie et le comportement des tokens :

vault write auth/userpass/users/bob \
    password="BobPassword123!" \
    policies="dev-policy" \
    token_ttl="8h" \
    token_max_ttl="24h" \
    token_bound_cidrs="10.0.0.0/8"

Paramètre	Description
token_ttl	Durée de vie initiale du token
token_max_ttl	Durée maximale (même après renouvellement)
token_bound_cidrs	IPs autorisées à utiliser le token

Glissez pour voir

AppRole : pour les applications et CI/CD

AppRole est la méthode recommandée pour les applications et pipelines. Elle utilise deux éléments :

• role_id : identité de l'application (stable, comme un username)
• secret_id : credential éphémère (comme un mot de passe temporaire)

Pourquoi AppRole ?

Userpass	AppRole
Mot de passe stable	secret_id éphémère et usage unique possible
Difficile à automatiser	Conçu pour l'automatisation
Pas de restriction d'usage	Limites sur nombre d'utilisations, TTL, CIDR

Glissez pour voir

Activer AppRole

vault auth enable approle

Créer un rôle

Créez un rôle pour votre application :

vault write auth/approle/role/my-webapp \
    secret_id_ttl=10m \
    token_num_uses=10 \
    token_ttl=20m \
    token_max_ttl=30m \
    secret_id_num_uses=1 \
    policies="webapp-policy"

Paramètre	Description	Valeur recommandée
secret_id_ttl	Durée de validité du secret_id	10-30 minutes
secret_id_num_uses	Nombre d'utilisations du secret_id	1 (usage unique)
token_ttl	Durée de vie du token obtenu	Selon besoin applicatif
token_num_uses	Nombre d'utilisations du token	0 (illimité) ou selon besoin

Glissez pour voir

secret_id_num_uses=1

En production, utilisez secret_id_num_uses=1. Chaque secret_id ne sert qu'une fois, ce qui limite l'impact en cas de fuite.

Obtenir les credentials

Récupérer le role_id

Le role_id est stable et peut être stocké dans la configuration de l'application :

vault read auth/approle/role/my-webapp/role-id

Sortie :

Key        Value
---        -----
role_id    d922482a-36c8-45fa-df77-c793b2980f51

Générer un secret_id

Le secret_id est éphémère et doit être généré à chaque déploiement :

vault write -f auth/approle/role/my-webapp/secret-id

Sortie :

Key                   Value
---                   -----
secret_id             aab71b03-aeeb-6965-dd97-73d5f9e30f38
secret_id_accessor    67eabeab-e4b4-12f3-8fde-4ab79b5c7027
secret_id_num_uses    1
secret_id_ttl         10m

Se connecter avec AppRole

L'application utilise role_id + secret_id pour obtenir un token :

vault write auth/approle/login \
    role_id="d922482a-36c8-45fa-df77-c793b2980f51" \
    secret_id="aab71b03-aeeb-6965-dd97-73d5f9e30f38"

Sortie :

Key                     Value
---                     -----
token                   hvs.CAESIG...
token_accessor          ABC123...
token_duration          20m
token_renewable         true
token_policies          ["default" "webapp-policy"]

Workflow CI/CD recommandé

Voici comment intégrer AppRole dans un pipeline CI/CD :

1. Pré-déploiement : un administrateur génère le secret_id et le passe au pipeline (variable secrète CI/CD)

2. Pipeline : récupère le role_id (stocké en config) et le secret_id (variable secrète)

3. Login : le pipeline fait vault write auth/approle/login pour obtenir un token

4. Accès secrets : le pipeline utilise le token pour lire les secrets nécessaires

5. Fin : le token expire automatiquement

Exemple de script :

#!/bin/bash
set -e

# Variables d'environnement (injectées par le CI/CD)
# VAULT_ADDR, VAULT_ROLE_ID, VAULT_SECRET_ID

# Obtenir le token
VAULT_TOKEN=$(vault write -field=token auth/approle/login \
    role_id="$VAULT_ROLE_ID" \
    secret_id="$VAULT_SECRET_ID")

export VAULT_TOKEN

# Lire les secrets
DB_PASSWORD=$(vault kv get -field=password secret/apps/webapp/database)

# Utiliser le secret...
echo "Deploying with DB access..."

Wrapped secret_id : sécurité renforcée

Pour éviter que le secret_id transite en clair, utilisez le response wrapping :

# Générer un secret_id wrappé (valide 5 minutes)
vault write -wrap-ttl=5m -f auth/approle/role/my-webapp/secret-id

Sortie :

Key                              Value
---                              -----
wrapping_token                   hvs.CAESI...
wrapping_accessor                abc123...
wrapping_token_ttl               5m
wrapping_token_creation_time     2026-03-16T14:30:00Z
wrapping_token_creation_path     auth/approle/role/my-webapp/secret-id

Le CI/CD reçoit un wrapping_token au lieu du secret_id. Il doit le "unwrapper" :

VAULT_TOKEN="<wrapping_token>" vault unwrap

Avantage du wrapping

Si le wrapping_token est intercepté et utilisé par un attaquant, le secret_id n'est plus disponible pour l'application légitime → attaque détectée.

Comparatif des méthodes

Aspect	Userpass	AppRole	Token
Cible	Humains	Applications	Automation simple
Facilité	Très simple	Moyen	Simple
Sécurité	Moyenne	Haute	Faible
Rotation	Manuelle	Automatisable	Manuelle
CI/CD	Non recommandé	Recommandé	Acceptable court-terme

Glissez pour voir

Dépannage

Symptôme	Cause probable	Solution
invalid username or password	Credentials incorrects	Vérifier username/password
invalid role_id	Rôle AppRole inexistant	vault read auth/approle/role/<nom>
secret_id is invalid	secret_id expiré ou déjà utilisé	Générer un nouveau secret_id
permission denied on login	Auth method non activée	vault auth enable <method>
request path is not valid	Path incorrect	Vérifier le path (auth/userpass/...)

Glissez pour voir

À retenir

1. userpass : simple, pour les utilisateurs humains (CLI, UI)
2. AppRole : sécurisé, pour applications et CI/CD
3. role_id = identité stable, secret_id = credential éphémère
4. En prod : secret_id_num_uses=1 pour usage unique
5. Response wrapping : protection supplémentaire pour les pipelines
6. Chaque utilisateur/application = policies spécifiques (moindre privilège)

Prochaines étapes

Policies Définir les permissions avec HCL

Secrets KV Stocker vos premiers secrets

Concepts Vault Architecture et vue d'ensemble

×

📖 Voir la documentation →