Dynamic credentials, tfe_outputs et run triggers

Stocker des clés cloud longue durée dans HCP Terraform fonctionne, mais pose un risque de sécurité : ces clés ne changent pas et peuvent fuiter. Les dynamic provider credentials résolvent ce problème en générant des tokens temporaires via OIDC à chaque run. Ce guide couvre aussi le partage d’état entre workspaces (tfe_outputs) et le chaînage automatique de runs (run triggers).

Ce que vous allez apprendre

• Le fonctionnement des dynamic credentials (OIDC workload identity)
• Comment configurer les dynamic credentials pour AWS
• Comment partager des outputs entre workspaces avec tfe_outputs
• Comment chaîner l’exécution de workspaces avec les run triggers

Dynamic provider credentials

Le problème des clés statiques

Sans dynamic credentials, vous stockez des clés cloud (AWS access key, GCP service account key) dans des variables d’environnement du workspace. Ces clés :

• ont une durée de vie longue (mois, voire années),
• doivent être rotées manuellement,
• sont identiques entre les runs (pas d’isolation),
• constituent un risque si elles sont exfiltrées.

La solution : OIDC workload identity

Analogie : le badge visiteur

Les clés statiques, c’est comme un passe permanent qui ouvre toutes les portes de l’immeuble. Les dynamic credentials, c’est un badge visiteur émis à chaque visite : il ouvre uniquement les portes nécessaires, expire au bout d’une heure et ne peut pas être réutilisé.

Les dynamic credentials fonctionnent avec OIDC (OpenID Connect) :

1. Au début d’un run, HCP Terraform génère un workload identity token — un JWT signé qui identifie le workspace et le run.
2. Ce token est envoyé au provider cloud (AWS, GCP, Azure) qui le vérifie.
3. Le provider cloud échange le token contre des credentials temporaires, valides pour la durée du plan ou de l’apply en cours.
4. Terraform utilise ces credentials temporaires pour le plan et l’apply.
5. À la fin du run, les credentials expirent automatiquement.

Les providers supportés :

Provider	Mécanisme côté cloud
AWS	IAM OIDC identity provider + rôle IAM avec trust policy
GCP	Workload Identity Federation + service account
Azure	Federated identity credential sur un App Registration
Vault	JWT auth method
Kubernetes	OIDC provider sur le cluster

Glissez pour voir

Configurer les dynamic credentials pour AWS

La configuration se fait en deux endroits : côté AWS (une seule fois) et côté HCP Terraform (par workspace ou variable set).

Côté AWS

1. Créez un OIDC identity provider dans IAM

   Dans la console AWS → IAM → Identity providers → Add provider :

   Champ	Valeur
   Provider type	OpenID Connect
   Provider URL	https://app.terraform.io
   Audience	aws.workload.identity

   Glissez pour voir

2. Créez un rôle IAM avec une trust policy

   Le rôle autorise HCP Terraform à assumer le rôle via le token OIDC :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/app.terraform.io"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "app.terraform.io:aud": "aws.workload.identity"
           },
           "StringLike": {
             "app.terraform.io:sub": "organization:stephrobert-terraform-labs:project:*:workspace:*:run_phase:*"
           }
         }
       }
     ]
   }

   Le champ sub filtre les workspaces autorisés. Cet exemple de lab autorise tous les workspaces de l’organisation. En production, ciblez au moins l’organisation, le project, le workspace, et séparez si possible les rôles plan et apply.

   Vérifiez au minimum aud et organization

   La trust policy doit toujours vérifier le champ aud et le nom d’organisation dans le sub. Sans ces vérifications, n’importe quelle organisation HCP Terraform pourrait assumer le rôle.

3. Attachez les permissions nécessaires au rôle

   Attachez une policy IAM qui donne les droits nécessaires (ex : AmazonEC2FullAccess pour un lab, ou des permissions minimales en production).

Côté HCP Terraform

Ajoutez les variables d’environnement suivantes dans le workspace ou un variable set — c’est la configuration minimale viable :

Variable	Valeur	Type
TFC_AWS_PROVIDER_AUTH	true	Environment variable
TFC_AWS_RUN_ROLE_ARN	arn:aws:iam::ACCOUNT_ID:role/terraform-hcp-role	Environment variable

Glissez pour voir

Pensez aussi à définir la région AWS via l’argument region du provider ou via la variable AWS_REGION.

Configuration avancée

Pour séparer les droits entre plan et apply, utilisez TFC_AWS_PLAN_ROLE_ARN et TFC_AWS_APPLY_ROLE_ARN au lieu de TFC_AWS_RUN_ROLE_ARN. D’autres variables sont disponibles pour les cas avancés :

• TFC_AWS_WORKLOAD_IDENTITY_AUDIENCE — personnalise l’audience du token
• TFC_DEFAULT_* — s’applique à tous les providers d’un même type
• Variantes [_TAG] — cible un alias de provider spécifique

Consultez la documentation HashiCorp pour la liste complète.

C’est tout pour le cas simple. Au prochain run, HCP Terraform génère automatiquement un token OIDC, assume le rôle AWS et utilise les credentials temporaires. Aucune clé statique n’est stockée.

Disponible en édition gratuite

Les dynamic credentials sont entièrement disponibles en édition gratuite. C’est la méthode recommandée par HashiCorp pour tous les environnements.

Partager des données entre workspaces : tfe_outputs

Le problème

Vos workspaces sont isolés par conception : le workspace « réseau » crée un VPC et le workspace « application » a besoin de l’ID de ce VPC pour déployer ses instances. Comment passer cette information ?

La solution : tfe_outputs

Le data source tfe_outputs lit les outputs d’un autre workspace de la même organisation. Il nécessite un provider tfe correctement authentifié :

data "tfe_outputs" "network" {
  organization = "stephrobert-terraform-labs"
  workspace    = "production-networking"
}

resource "aws_instance" "app" {
  subnet_id = data.tfe_outputs.network.nonsensitive_values.subnet_id
  # ...
}

Syntaxe et accès aux valeurs

Selon la version du provider tfe, l’accès aux outputs se fait via .nonsensitive_values.<output> (forme courante dans les tutoriels) ou via .values.<output>. Certaines versions récentes utilisent une forme avec bloc config. Consultez la documentation du provider tfe pour la syntaxe exacte correspondant à votre version.

Analogie : la boîte aux lettres entre bureaux

Chaque workspace dépose ses outputs dans sa boîte aux lettres. tfe_outputs permet à un autre workspace de lire cette boîte sans avoir accès au bureau complet (state). C’est du partage en lecture seule.

Configuration requise

Pour que tfe_outputs fonctionne :

• Le workspace source doit avoir des outputs définis et appliqués.
• Le workspace consommateur doit disposer d’un provider tfe authentifié avec un token valide (TFE_TOKEN en variable d’environnement) et les permissions de lecture sur le workspace source. Les règles classiques de remote state sharing ne s’appliquent pas à tfe_outputs — c’est le token du provider tfe qui contrôle l’accès.
• Les outputs marqués sensitive = true sont accessibles mais restent masqués dans les logs.

Exemple complet

Workspace « réseau » — crée le VPC et expose l’ID :

output "vpc_id" {
  value       = aws_vpc.main.id
  description = "ID du VPC principal"
}

output "subnet_ids" {
  value       = aws_subnet.private[*].id
  description = "IDs des subnets privés"
}

Workspace « application » — consomme les outputs du workspace « réseau » :

data "tfe_outputs" "network" {
  organization = "stephrobert-terraform-labs"
  workspace    = "production-networking"
}

resource "aws_instance" "app" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"
  subnet_id     = data.tfe_outputs.network.nonsensitive_values.subnet_ids[0]

  tags = {
    VPC = data.tfe_outputs.network.nonsensitive_values.vpc_id
  }
}

tfe_outputs vs terraform_remote_state

tfe_outputs est spécifique à HCP Terraform et lit uniquement les outputs. terraform_remote_state est générique (fonctionne avec tous les backends) mais expose potentiellement tout le state. Préférez tfe_outputs dans HCP Terraform pour limiter la surface d’exposition.

Chaîner les runs : run triggers

Le problème

Quand le workspace « réseau » change un subnet, le workspace « application » doit recalculer son plan pour vérifier que tout est cohérent. Sans automatisation, il faut penser à lancer manuellement un run dans chaque workspace dépendant.

La solution : run triggers

Un run trigger configure une relation « quand le workspace source termine un apply, le workspace dépendant démarre automatiquement un run ».

Configuration

Dans le workspace dépendant (celui qui doit réagir) :

1. Allez dans Settings → Run Triggers.
2. Ajoutez le workspace source (celui qui déclenche).

Quand le workspace source termine un apply avec succès, le workspace dépendant démarre automatiquement un run.

Workspace source	Workspace dépendant	Ce qui se passe
production-networking	production-app	Un apply du réseau déclenche un plan de l’application
production-networking	production-monitoring	Un apply du réseau déclenche un plan du monitoring

Glissez pour voir

Limites et précautions

• Les run triggers déclenchent un plan (pas un apply direct). Par défaut, l’apply nécessite une approbation si le workspace est en manual apply.
• Il existe un réglage dédié Auto-apply run triggers dans les settings du workspace, indépendant du réglage principal d’auto-apply. Activez-le si vous voulez que les runs déclenchés par trigger s’appliquent automatiquement.
• Évitez les chaînes circulaires : A déclenche B qui déclenche A → boucle infinie.
• Un workspace peut avoir jusqu’à 20 run triggers en source.

Run triggers vs depends_on

Les run triggers ne remplacent pas depends_on dans le code HCL. depends_on ordonne les ressources dans un même workspace. Les run triggers ordonnent les runs entre workspaces différents. Ce sont deux mécanismes complémentaires à des niveaux différents.

Combiner les trois mécanismes

En pratique, les dynamic credentials, tfe_outputs et les run triggers s’utilisent ensemble :

Mécanisme	Ce qu’il résout
Dynamic credentials	S’authentifier auprès du cloud sans clés statiques
tfe_outputs	Lire les données produites par un autre workspace
Run triggers	Déclencher automatiquement un recalcul quand une dépendance change

Glissez pour voir

Exemple de chaîne complète :

1. Le workspace networking s’authentifie via dynamic credentials et crée un VPC.
2. Le workspace app lit le VPC ID via tfe_outputs et déploie les instances.
3. Un run trigger garantit que tout changement dans networking déclenche un nouveau plan dans app.

Dépannage

Symptôme	Cause probable	Solution
Error: could not assume role lors du plan	Trust policy AWS mal configurée	Vérifiez le champ sub et l’ARN du provider OIDC
Error: Unauthorized sur tfe_outputs	Token tfe manquant ou insuffisant	Vérifiez que TFE_TOKEN est défini dans le workspace consommateur avec les bonnes permissions
Le run trigger ne se déclenche pas	Le workspace source a fait un plan sans apply	Les run triggers ne se déclenchent que sur un apply réussi
Credentials temporaires expirées	Run trop long	Augmentez la durée de session dans la trust policy AWS
tfe_outputs retourne des valeurs vides	Le workspace source n’a pas encore fait d’apply	Lancez un apply dans le workspace source d’abord
Boucle infinie de run triggers	Chaîne circulaire A → B → A	Supprimez le trigger circulaire

Glissez pour voir

À retenir

• Les dynamic credentials génèrent des tokens temporaires via OIDC à chaque run — plus besoin de clés cloud statiques. Disponibles en édition gratuite.
• Côté AWS, la configuration nécessite un OIDC identity provider et un rôle IAM avec trust policy. Vérifiez toujours aud et l’organisation dans le sub. Côté HCP Terraform, deux variables d’environnement suffisent pour un cas simple.
• tfe_outputs lit les outputs d’un autre workspace via le provider tfe authentifié (token TFE_TOKEN). Préférez-le à terraform_remote_state pour limiter l’exposition.
• Les run triggers chaînent les runs entre workspaces : un apply dans le workspace source déclenche un plan dans le workspace dépendant. Le réglage Auto-apply run triggers permet l’apply automatique.
• Ces trois mécanismes se combinent naturellement : credentials sans clé, partage de données, déclenchement automatique.
• Évitez les chaînes circulaires de run triggers.

Prochaines étapes

Policy as Code et governance Sentinel, OPA, policy sets et niveaux d'application.

Variables, secrets et variable sets Centraliser les variables et gérer les variable sets.

Remote runs et modes d'exécution CLI-driven, VCS-driven, speculative plans.

×

📖 Voir la documentation →