Vault AWS : credentials IAM dynamiques

Vault AWS secrets engine génère des credentials IAM temporaires à la demande. Plus d’access keys permanentes dans le code : chaque workload obtient ses propres credentials, valides quelques heures maximum.

Ce guide couvre les trois types de credentials AWS que Vault peut émettre et leur cas d’usage.

Pourquoi des credentials AWS dynamiques

Access keys permanentes	Avec Vault AWS
Durée de vie illimitée	TTL 1-12h max
Partagées via secrets/env vars	Générées à la demande
Rotation manuelle rare	Rotation automatique par TTL
Compromission = accès permanent	Compromission = accès limité dans le temps
Audit : “qui a cette clé ?”	Audit : “quel workload a demandé quand”

Glissez pour voir

Le vrai risque

Une access key AWS committée sur GitHub est exploitable en minutes par des bots de scanning. Si elle est permanente, votre compte reste compromis jusqu’à la détection et la révocation manuelle.

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
• Compte AWS avec permissions IAM pour créer des credentials

Types de credentials : iam_user vs assumed_role vs federation_token

Vault peut émettre trois types de credentials AWS :

Type	Comment ça marche	TTL typique	Cas d’usage
iam_user	Vault crée un user IAM + access key	∞ (mais lease Vault)	Legacy, permissions complexes
assumed_role	Vault assume un rôle IAM via STS	1-12h (borne AWS)	Recommandé - standard
federation_token	Vault génère un token fédéré	Jusqu’à 36h	Console AWS, accès humain

Glissez pour voir

TTL dépendant de la configuration

Les TTL maximaux dépendent de la configuration AWS du rôle STS cible et des paramètres default_sts_ttl / max_sts_ttl configurés dans Vault. Les valeurs ci-dessus sont des bornes usuelles, pas des limites universelles.

Préférez assumed_role

assumed_role est le mode recommandé :

• Pas de création d’entité IAM (plus propre)
• Credentials STS nativement temporaires
• Pas d’entité IAM persistante à nettoyer

Étape 1 : activer le moteur AWS

vault secrets enable aws

Étape 2 : configurer les credentials root

Vault a besoin de credentials pour appeler les API AWS. Deux options :

Access key (simple)

vault write aws/config/root \
    access_key="AKIAIOSFODNN7EXAMPLE" \
    secret_key="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
    region="eu-west-1"

IAM role (EC2/ECS/EKS)

Si Vault tourne sur AWS avec un IAM role attaché (instance profile, task role, IRSA), vous pouvez utiliser ce rôle directement :

vault write aws/config/root \
    region="eu-west-1"
    # Pas de credentials : Vault utilise le rôle de l'instance

Privilégiez l'identité native AWS

Si Vault tourne sur AWS (EC2, ECS, EKS), privilégiez l’identité native de la plateforme (instance profile, task role, IRSA) plutôt qu’une paire access key / secret key statique dans aws/config/root. C’est plus sécurisé et évite de gérer une rotation des credentials root.

Permissions requises

Le compte/rôle root doit pouvoir :

• iam_user : iam:CreateUser, iam:CreateAccessKey, iam:DeleteUser, etc.
• assumed_role : sts:AssumeRole sur les rôles cibles
• federation_token : sts:GetFederationToken

Rotation des credentials root

Après configuration avec access key :

vault write -force aws/config/rotate-root

Pas de retour en arrière

Après rotation, seul Vault connaît l’access key. Gardez un accès de secours via la console AWS. Ce compte root sert uniquement au moteur AWS de Vault, ne le réutilisez pas ailleurs.

Étape 3 : créer un rôle

assumed_role (recommandé)

Le rôle Vault référence un rôle IAM existant dans AWS :

vault write aws/roles/deploy \
    credential_type="assumed_role" \
    role_arns="arn:aws:iam::123456789012:role/DeployRole" \
    default_sts_ttl="1h" \
    max_sts_ttl="4h"

Prérequis AWS : le rôle DeployRole doit avoir une trust policy permettant à Vault (via son rôle ou user) de l’assumer :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/vault-aws"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Rôle Vault ≠ rôle IAM

Le nom du rôle Vault (deploy) n’est pas le rôle IAM lui-même. C’est une configuration Vault qui encapsule un ou plusieurs role_arns AWS cibles. Le rôle Vault définit qui peut demander des credentials et vers quel(s) rôle(s) IAM AWS.

iam_user

Vault crée un user IAM temporaire avec une policy inline :

vault write aws/roles/s3-readonly \
    credential_type="iam_user" \
    policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]
    }
  ]
}
EOF

Ou avec des policies managées :

vault write aws/roles/ec2-admin \
    credential_type="iam_user" \
    policy_arns="arn:aws:iam::aws:policy/AmazonEC2FullAccess"

federation_token

Pour l’accès console ou des workloads spécifiques :

vault write aws/roles/console-readonly \
    credential_type="federation_token" \
    policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:Describe*", "s3:List*"],
      "Resource": "*"
    }
  ]
}
EOF

federation_token : cas spécialisé

federation_token reste un mode supporté, mais assumed_role couvre la majorité des besoins modernes côté workloads et automation. Réservez federation_token aux cas où vous avez besoin d’un accès console AWS ou d’un TTL plus long que ce que permet assumed_role.

Étape 4 : émettre des credentials temporaires

vault read aws/creds/deploy

Sortie (pour assumed_role) :

Key                Value
---                -----
lease_id           aws/creds/deploy/abcd1234
lease_duration     1h
lease_renewable    true
access_key         ASIAIOSFODNN7EXAMPLE
secret_key         wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
security_token     FwoGZXIvYXdzEBY...
arn                arn:aws:sts::123456789012:assumed-role/DeployRole/vault-token-xyz

Ce qui se passe :

1. Vault appelle sts:AssumeRole avec le rôle IAM configuré
2. AWS retourne des credentials STS temporaires
3. Vault crée un lease et retourne les credentials
4. L’application utilise ces credentials
5. À expiration, les credentials STS deviennent invalides (côté AWS)

Utiliser les credentials

export AWS_ACCESS_KEY_ID="ASIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="FwoGZXIvYXdzEBY..."

aws s3 ls

Session token obligatoire

Pour assumed_role et federation_token, le security_token (session token) est obligatoire. Sans lui, les appels AWS échoueront.

Static role : rotation d’une clé IAM existante

Pour les cas où vous avez besoin d’une access key fixe mais rotée automatiquement :

vault write aws/static-roles/ci-user \
    name="ci-user" \
    username="ci-pipeline-user" \
    rotation_period="24h"

Adoption d'un user IAM existant

Lorsqu’un static role est créé, Vault doit connaître une credential valide pour cet utilisateur IAM. Si nécessaire, Vault génère une nouvelle access key et peut faire tourner la plus ancienne s’il y a déjà le maximum de clés (2 par user IAM).

Lecture :

vault read aws/static-creds/ci-user

Différence avec dynamic :

• Même user IAM (ci-pipeline-user)
• Access key rotée tous les 24h
• Pas de session token

Static = compromis

Le static role est un compromis pour les outils qui ne supportent pas les credentials STS (rares aujourd’hui). Préférez assumed_role.

Révocation

Révoquer un lease

vault lease revoke aws/creds/deploy/abcd1234

Ce qui se passe selon le type :

• iam_user : Vault supprime l’access key et l’user IAM
• assumed_role : Vault marque le lease comme révoqué (les credentials STS expirent naturellement, pas de révocation AWS)
• federation_token : idem assumed_role

Révocation STS

Les credentials STS (assumed_role, federation_token) ne peuvent pas être révoqués côté AWS. Ils expirent simplement à leur TTL. C’est pourquoi des TTL courts (1-4h) sont recommandés.

Révoquer tous les credentials d’un rôle

vault lease revoke -prefix aws/creds/deploy

Policy Vault pour l’accès AWS

policy-deploy.hcl

# Obtenir des credentials AWS pour le déploiement
path "aws/creds/deploy" {
  capabilities = ["read"]
}

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

vault policy write deploy policy-deploy.hcl

Renouvellement ou redemande ?

La policy sys/leases/renew permet le renouvellement explicite. En pratique, beaucoup de workloads préfèrent redemander de nouveaux credentials plutôt que renouveler, ou délèguent à un agent (Vault Agent, vault-action). Adaptez selon votre architecture.

Intégration CI/CD

GitHub Actions

name: Deploy to AWS
on:
  push:
    branches: [main]

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

      - name: Import Secrets from Vault
        uses: hashicorp/vault-action@v2
        with:
          url: https://vault.example.com
          method: jwt
          role: github-deploy
          secrets: |
            aws/creds/deploy access_key | AWS_ACCESS_KEY_ID ;
            aws/creds/deploy secret_key | AWS_SECRET_ACCESS_KEY ;
            aws/creds/deploy security_token | AWS_SESSION_TOKEN

      - name: Deploy
        run: |
          aws s3 sync ./dist s3://my-app-bucket

JWT auth pour CI/CD

GitHub Actions peut s’authentifier à Vault via OIDC/JWT sans secret permanent. Vault vérifie l’identité du workflow via le token OIDC de GitHub.

GitLab CI

deploy:
  stage: deploy
  script:
    - export VAULT_ADDR="https://vault.example.com"
    - export VAULT_TOKEN=$(vault write -field=token auth/jwt/login role=gitlab-deploy jwt=$CI_JOB_JWT)
    - eval $(vault read -format=json aws/creds/deploy | jq -r '.data | "export AWS_ACCESS_KEY_ID=\(.access_key) AWS_SECRET_ACCESS_KEY=\(.secret_key) AWS_SESSION_TOKEN=\(.security_token)"')
    - aws s3 sync ./dist s3://my-app-bucket

Dépannage

Symptôme	Cause probable	Solution
permission denied	Policy Vault manquante	Vérifier aws/creds/<role>
AccessDenied côté AWS	Trust policy incorrecte	Vérifier sts:AssumeRole
ExpiredToken	TTL dépassé	Renouveler ou obtenir de nouveaux creds
InvalidIdentityToken	Horloge désynchronisée	Vérifier NTP sur Vault
User IAM non supprimé	Permissions IAM manquantes	Vérifier iam:DeleteUser, iam:DeleteAccessKey

Glissez pour voir

Debug

# Vérifier la configuration
vault read aws/config/root

# Lister les rôles
vault list aws/roles

# Vérifier un rôle spécifique
vault read aws/roles/deploy

# Tester une émission
vault read aws/creds/deploy

# Vérifier les leases actifs
vault list sys/leases/lookup/aws/creds/deploy

Ce que le moteur AWS ne fait pas

Responsabilité	Vault	Vous
Générer des credentials STS	✅	—
Gérer les TTL et leases	✅	—
Créer les rôles IAM cibles	❌	✅
Configurer les trust policies	❌	✅
Révoquer les credentials STS côté AWS	❌	N/A (expire naturellement)
Monitorer l’usage AWS	❌	✅ (CloudTrail)

Glissez pour voir

CloudTrail

Même avec Vault, activez CloudTrail pour auditer l’usage des credentials. Vault trace l’émission, CloudTrail trace l’utilisation.

À retenir

1. assumed_role : mode recommandé, pas de création d’entité IAM
2. iam_user : Vault crée un user temporaire, plus de cleanup
3. federation_token : pour la console AWS ou workloads spécifiques
4. TTL courts : 1-4h, les credentials STS ne sont pas révocables
5. Trust policy : le rôle IAM doit autoriser Vault à l’assumer
6. Static role : rotation d’une clé existante (compromis pour legacy)
7. Audit : Vault trace l’émission, CloudTrail trace l’utilisation

Prochaines étapes

SSH secrets Certificats SSH signés

Database secrets Credentials PostgreSQL/MySQL dynamiques

Identity broker Vault comme courtier d'identité

×

📖 Voir la documentation →