Vault Database : credentials dynamiques pour PostgreSQL, MySQL, MongoDB

Vault Database secrets engine génère des credentials de base de données à la demande, avec une durée de vie limitée. Chaque service obtient son propre user/password, révocable individuellement.

Ce guide couvre PostgreSQL, MySQL et MongoDB, mais le principe s’applique à tous les plugins database supportés par Vault.

Pourquoi des credentials dynamiques pour les bases de données

Modèle classique	Avec Vault Database
Un compte partagé app_user	Un compte par workload v-token-app-xyz
Password dans le code/env	Password généré à la demande
Rotation manuelle annuelle	Dynamic role : émission éphémère + révocation
Compromission = tout exposé	Compromission = un seul workload
Audit : “app_user a fait X”	Audit : “v-token-svc-abc a fait X”

Glissez pour voir

Le vrai gain

Ce n’est pas juste la rotation automatique. C’est la traçabilité : chaque requête SQL est associée à un workload précis, pas à un compte générique.

Prérequis

Secrets dynamiques Concepts lease, TTL, révocation

Policies Contrôler l'accès aux credentials

• Vault installé et démarré
• Accès admin pour configurer le moteur
• Base de données PostgreSQL, MySQL ou MongoDB accessible depuis Vault
• Compte de gestion dédié à Vault pour créer/supprimer des utilisateurs

Compte de gestion (root user)

La doc Vault appelle ce compte “root user”, mais ce n’est pas forcément le superuser absolu de la base. C’est le compte dédié à Vault pour gérer les utilisateurs dynamiques et statiques. Donnez-lui uniquement les privilèges nécessaires (CREATE ROLE, GRANT, etc.), pas tous les droits.

Architecture du moteur Database

Composants :

• Connection : configuration de l’accès à la DB (URL, admin credentials)
• Role : template SQL + TTL pour les credentials générés
• Lease : référence au credential émis, pour renouvellement/révocation

Plugins par moteur

Le moteur Database s’appuie sur un plugin spécifique au type de base : PostgreSQL, MySQL/MariaDB, MongoDB, Oracle, MSSQL, etc. Le comportement exact des creation_statements et revocation_statements dépend du plugin.

Étape 1 : activer le moteur et configurer la connexion

Activer le moteur

vault secrets enable database

Configurer la connexion PostgreSQL

PostgreSQL

vault write database/config/postgres \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="readonly,readwrite" \
    connection_url="postgresql://{{username}}:{{password}}@postgres.example.com:5432/myapp?sslmode=require" \
    username="vault_admin" \
    password="VaultAdminPassword123"

MySQL

vault write database/config/mysql \
    plugin_name="mysql-database-plugin" \
    allowed_roles="readonly,readwrite" \
    connection_url="{{username}}:{{password}}@tcp(mysql.example.com:3306)/myapp" \
    username="vault_admin" \
    password="VaultAdminPassword123"

MongoDB

vault write database/config/mongodb \
    plugin_name="mongodb-database-plugin" \
    allowed_roles="readonly,readwrite" \
    connection_url="mongodb://{{username}}:{{password}}@mongo.example.com:27017/admin?tls=true" \
    username="vault_admin" \
    password="VaultAdminPassword123"

Compte de gestion Vault

Le compte vault_admin doit avoir les droits de créer/supprimer des utilisateurs sur la DB. Vault l’utilise pour :

• Créer les users dynamiques
• Les supprimer à la révocation

Ce compte n’est jamais exposé aux applications. Donnez-lui uniquement les privilèges nécessaires, pas les droits de superuser absolu.

Rotation du mot de passe admin

Après configuration, faites tourner le mot de passe admin pour que seul Vault le connaisse :

vault write -force database/rotate-root/postgres

Pas de retour en arrière

Après cette commande, vous ne connaissez plus le mot de passe admin. Seul Vault peut accéder à la DB. Planifiez un accès de secours avant.

Étape 2 : créer un rôle dynamique

Un rôle définit :

• Le template SQL pour créer l’utilisateur
• Les permissions accordées
• Le TTL (durée de vie)

PostgreSQL readonly

vault write database/roles/readonly \
    db_name="postgres" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
        GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    revocation_statements="REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM \"{{name}}\"; \
        DROP ROLE IF EXISTS \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

PostgreSQL readwrite

vault write database/roles/readwrite \
    db_name="postgres" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
        GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    revocation_statements="REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM \"{{name}}\"; \
        DROP ROLE IF EXISTS \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="8h"

MySQL readonly

vault write database/roles/readonly \
    db_name="mysql" \
    creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; \
        GRANT SELECT ON myapp.* TO '{{name}}'@'%';" \
    revocation_statements="DROP USER IF EXISTS '{{name}}'@'%';" \
    default_ttl="1h" \
    max_ttl="24h"

Statements minimaux

Ces exemples sont volontairement simplifiés. En PostgreSQL réel, il faut souvent aussi gérer :

• GRANT USAGE ON SCHEMA public TO "{{name}}";
• les default privileges pour les tables créées après le GRANT
• les séquences (GRANT SELECT ON ALL SEQUENCES...) si besoin

Consultez la doc du plugin PostgreSQL pour des exemples complets.

MongoDB : même principe, syntaxe différente

Le moteur Database fonctionne aussi pour MongoDB, mais les creation_statements ne sont pas du SQL. MongoDB utilise des documents JSON pour définir les rôles et privilèges. Référez-vous aux exemples spécifiques du plugin MongoDB.

Variables disponibles :

Variable	Description
{{name}}	Username généré par Vault
{{password}}	Password généré par Vault
{{expiration}}	Date d’expiration (PostgreSQL VALID UNTIL)

Glissez pour voir

Étape 3 : émettre des credentials

vault read database/creds/readonly

Sortie :

Key                Value
---                -----
lease_id           database/creds/readonly/abcd1234-5678-90ef
lease_duration     1h
lease_renewable    true
password           A1B2-c3D4-e5F6-g7H8
username           v-token-readonly-xyz123abc

Ce qui se passe :

1. Vault se connecte à PostgreSQL avec le compte admin
2. Vault exécute le creation_statements avec un username/password générés
3. Vault retourne les credentials et crée un lease
4. L’application utilise ces credentials
5. À expiration (ou révocation), Vault exécute revocation_statements

Vérifier côté PostgreSQL

-- Lister les utilisateurs Vault
SELECT usename, valuntil FROM pg_user WHERE usename LIKE 'v-%';

-- Résultat
         usename          |        valuntil
--------------------------+------------------------
 v-token-readonly-xyz123  | 2026-03-16 15:00:00+00

Static role : rotation d’un compte existant

Pour les applications legacy qui ne supportent pas les credentials dynamiques, Vault peut gérer un compte existant et le faire tourner automatiquement.

Créer un static role

vault write database/static-roles/legacy-app \
    db_name="postgres" \
    username="legacy_app_user" \
    rotation_statements="ALTER ROLE \"{{name}}\" WITH PASSWORD '{{password}}';" \
    rotation_period="24h"

Lire les credentials

vault read database/static-creds/legacy-app

Sortie :

Key                    Value
---                    -----
last_vault_rotation    2026-03-16T10:00:00Z
password               NewRotatedPass123
rotation_period        24h
ttl                    23h45m
username               legacy_app_user

Différence avec dynamic role :

• Le username est toujours le même (legacy_app_user)
• Le password change automatiquement tous les rotation_period
• Pas de lease à renouveler, mais le password change

Ne pas gérer le compte de gestion via static role

N’utilisez jamais un static role pour gérer le même compte que celui configuré dans database/config/.... Après rotation par le static role, Vault ne connaîtrait plus le bon mot de passe pour ses propres opérations.

Pour le compte de gestion, utilisez uniquement rotate-root.

Static role : compromis legacy

Le static role est un compromis pour les apps qui ne supportent pas les credentials dynamiques. Vous gardez la rotation automatique, mais perdez la traçabilité par workload. Préférez les dynamic roles pour les nouvelles applications.

Dynamic role : pas une rotation

Avec les dynamic roles, ce n’est pas vraiment une “rotation” : chaque requête émet un nouveau credential qui expire et sera révoqué. Le compte précédent n’est pas “mis à jour”, il est supprimé.

La vraie rotation périodique automatique s’applique aux static roles (et au root credential via rotate-root).

Choisir dynamic role ou static role

Cas d’usage	Choix	Raison
Nouvelle application	Dynamic role	Traçabilité par workload
Appli legacy avec user fixe imposé	Static role	Pas d’alternative
Besoin d’audit précis par service	Dynamic role	Username unique = audit clair
Outil sans support de relecture credentials	Static role	Password stable entre rotations
Connexions éphémères (jobs, CI)	Dynamic role	TTL très court possible
Connexion longue durée (pool)	Dynamic role + renouvellement	Ou static role si legacy

Glissez pour voir

Révocation et renouvellement

Renouveler un lease

Avant expiration, l’application peut prolonger :

vault lease renew database/creds/readonly/abcd1234-5678-90ef

Le renouvellement est limité par le max_ttl du rôle.

Révoquer un lease

# Révoquer un credential spécifique
vault lease revoke database/creds/readonly/abcd1234-5678-90ef

# Révoquer tous les credentials d'un rôle
vault lease revoke -prefix database/creds/readonly

Action réelle : Vault exécute les revocation_statements et supprime l’utilisateur de la base de données.

Forcer une rotation (static role)

vault write -force database/rotate-role/legacy-app

Policy pour l’accès database

policy-app-readonly.hcl

# Obtenir des credentials readonly
path "database/creds/readonly" {
  capabilities = ["read"]
}

# Renouveler ses propres leases
path "sys/leases/renew" {
  capabilities = ["update"]
}

vault policy write app-readonly policy-app-readonly.hcl

Renouvellement ou redemande ?

Selon l’intégration, l’application peut :

• Renouveler son lease avant expiration (sys/leases/renew)
• Redemander de nouveaux credentials (database/creds/...)
• Déléguer à Vault Agent qui gère le cycle

Le choix dépend de la capacité de l’app à recharger ses connexions.

Principe du moindre privilège

Chaque application ne doit accéder qu’au rôle dont elle a besoin :

• Service de lecture → database/creds/readonly
• Service d’écriture → database/creds/readwrite
• Admin → database/creds/admin (avec TTL très court)

Intégration applicative

Exemple Python avec psycopg2

import hvac
import psycopg2
from contextlib import contextmanager

def get_db_credentials():
    """Obtenir des credentials dynamiques depuis Vault."""
    client = hvac.Client(url='https://vault.example.com')
    # Auth via AppRole, Kubernetes, etc.
    client.auth.approle.login(
        role_id='app-role-id',
        secret_id='app-secret-id'
    )

    # Lire les credentials dynamiques
    creds = client.secrets.database.generate_credentials(
        name='readonly',
        mount_point='database'
    )

    return {
        'user': creds['data']['username'],
        'password': creds['data']['password'],
        'lease_id': creds['lease_id'],
        'lease_duration': creds['lease_duration']
    }

@contextmanager
def get_db_connection():
    """Context manager avec credentials dynamiques."""
    creds = get_db_credentials()

    conn = psycopg2.connect(
        host='postgres.example.com',
        database='myapp',
        user=creds['user'],
        password=creds['password']
    )

    try:
        yield conn
    finally:
        conn.close()
        # Optionnel : révoquer immédiatement si TTL court
        # client.sys.revoke_lease(creds['lease_id'])

# Utilisation
with get_db_connection() as conn:
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM users LIMIT 10")
    rows = cursor.fetchall()

Exemple simplifié

Ce code montre l’obtention initiale des credentials. En production, il faut aussi traiter :

• le renouvellement avant expiration
• le rechargement du pool de connexions
• le comportement en cas d’échec de renouvellement ou d’expiration

Vault Agent avec template

Pour les applications qui ne peuvent pas appeler Vault directement :

agent-config.hcl

template {
  contents = <<EOF
[database]
host = postgres.example.com
port = 5432
database = myapp
{{ with secret "database/creds/readonly" }}
username = {{ .Data.username }}
password = {{ .Data.password }}
{{ end }}
EOF
  destination = "/etc/myapp/db.conf"
  perms = "0600"
  command = "systemctl reload myapp"
}

Vault Agent : pas magique

Vault Agent peut re-rendre le fichier de configuration quand les credentials changent, mais c’est à l’application (ou au hook command) de recharger proprement la configuration et les connexions DB.

Si l’app ne supporte pas le reload, elle devra être redémarrée.

Dépannage

Symptôme	Cause probable	Solution
permission denied	Policy manquante	Vérifier database/creds/<role>
connection refused	Vault ne peut pas joindre la DB	Vérifier réseau/firewall
authentication failed	Credentials admin invalides	Vérifier la config connection
role not found	Rôle inexistant ou mal nommé	vault list database/roles
TTL exceeds max	TTL demandé > max_ttl	Réduire le TTL ou augmenter max_ttl
User non supprimé après révocation	revocation_statements incorrect	Vérifier la syntaxe SQL

Glissez pour voir

Debug de la connexion

# Vérifier la configuration
vault read database/config/postgres

# Tester une émission
vault read database/creds/readonly

# Vérifier les leases actifs
vault list sys/leases/lookup/database/creds/readonly

Ce que le moteur Database ne fait pas

Responsabilité	Vault	Vous
Créer des users dynamiques	✅	—
Révoquer à expiration	✅	—
Stocker les credentials	❌	✅ (le temps d’un lease)
Gérer le pool de connexions	❌	✅
Migrer les apps existantes	❌	✅
Monitorer les expirations	❌*	✅
Backup de la DB	❌	✅

Glissez pour voir

*Vault expose des métriques, mais le monitoring est à votre charge.

Renouvellement applicatif

L’application doit gérer le renouvellement ou la récupération de nouveaux credentials avant expiration. Vault ne pousse pas les credentials, l’app doit les demander.

À retenir

1. Dynamic role : nouveau credential par requête, traçabilité parfaite
2. Static role : rotation périodique d’un compte existant (legacy uniquement)
3. Connection : compte de gestion dédié à Vault (pas le superuser DB)
4. rotate-root : après config, seul Vault connaît le mot de passe de gestion
5. Lease : identifiant pour renouveler ou révoquer un dynamic credential
6. Révocation : action réelle, l’user est supprimé de la DB
7. Plugins : création_statements dépendent du moteur (PostgreSQL ≠ MongoDB)
8. Intégration : l’app doit gérer renouvellement et rechargement des connexions

Prochaines étapes

AWS secrets Credentials IAM dynamiques

SSH secrets Certificats SSH signés

Secrets dynamiques Concepts et comparaison

×

📖 Voir la documentation →