Terraform Enterprise : passer de Terraform « sur mon poste » à Terraform en équipe - DevOps

Terraform tout seul sur son poste, c'est confortable. À dix, ça devient vite autre chose. Chacun a ses propres clés du cloud dans un fichier quelque part. Il faut que tout le monde configure correctement le backend et le verrou. Quelqu'un lance un apply depuis une branche qui n'a pas été relue. Et quand on demande « qui a supprimé ce sous-réseau mardi ? », la seule réponse honnête est un haussement d'épaules.

Terraform Enterprise répond à ces problèmes-là. Ce n'est pas un autre outil : c'est Terraform, exécuté de façon centralisée, avec une interface, des droits, un historique et des garde-fous. Voici ce que j'en retiens, à travers le cours vidéo et quelques exemples concrets.

Terraform Enterprise, HCP Terraform, Terraform Cloud : qui est qui ?

Les noms ont changé plusieurs fois, ce qui n'aide pas :

HCP Terraform (anciennement Terraform Cloud) : la version SaaS, hébergée par HashiCorp.
Terraform Enterprise : la même plateforme, que vous installez chez vous (sur vos serveurs ou votre cloud). C'est le choix des organisations qui ne peuvent pas faire sortir leur state ou leurs exécutions de leur périmètre.

Les concepts sont identiques entre les deux. Tout ce qui suit s'applique aux deux.

Organisation et workspaces

Tout est rangé dans une organisation. À l'intérieur, chaque infrastructure devient un workspace : un dossier de code Terraform, avec son propre state, ses variables, ses droits et son historique d'exécutions.

Exemples typiques : reseau-prod, reseau-dev, app-boutique-prod. Les workspaces peuvent être regroupés en projets pour organiser les droits par équipe.

Le state, enfin géré pour vous

Fini le bucket S3, la table de verrous et les politiques d'accès à configurer soi-même. Le state est stocké par la plateforme : chiffré, versionné (chaque apply en crée une nouvelle version, consultable et restaurable), et verrouillé automatiquement pendant chaque exécution. On peut aussi verrouiller un workspace manuellement pendant une opération sensible.

Étape 1 : relier un workspace à Git

Le mode le plus intéressant est le workflow VCS : le workspace est connecté à un dépôt GitHub, GitLab, Bitbucket ou Azure DevOps.

Chaque pull request déclenche automatiquement un plan spéculatif, dont le résultat s'affiche directement dans la PR. Les relecteurs voient l'impact réel du changement avant de valider.
Quand le code est fusionné, un run complet démarre : plan, contrôles de policies, estimation des coûts, puis apply après confirmation (ou automatiquement si vous l'avez activé).

Les exécutions tournent sur les serveurs de la plateforme, plus sur le poste de quelqu'un. Plus besoin que chaque membre de l'équipe ait les clés de production.

Étape 2 : les variables

Dans chaque workspace, deux types de variables :

Variables Terraform : l'équivalent des .tfvars (région, taille d'instance…).
Variables d'environnement : typiquement les identifiants du cloud (AWS_ACCESS_KEY_ID, ARM_CLIENT_SECRET…).

Une variable marquée sensitive est chiffrée et devient illisible pour tout le monde, administrateurs compris : on peut la remplacer, pas la relire. Et les variable sets permettent de partager un jeu de variables entre plusieurs workspaces, par exemple les identifiants d'un compte cloud commun.

Étape 3 : les règles de sécurité en code

C'est, pour moi, la fonctionnalité qui justifie le plus la plateforme. Des policies, écrites en Sentinel (le langage de HashiCorp) ou en OPA/Rego, vérifient chaque plan avant l'apply :

import "tfplan/v2" as tfplan

# Toute instance créée ou modifiée doit porter l'étiquette cost-center
instances = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_instance" and
  (rc.change.actions contains "create" or rc.change.actions contains "update")
}

main = rule {
  all instances as _, i {
    i.change.after.tags contains "cost-center"
  }
}

Exemples de règles classiques : interdire tout stockage public, imposer une étiquette cost-center sur chaque ressource, limiter les tailles d'instance autorisées en dev. Chaque policy a un niveau d'application : advisory (simple avertissement), soft-mandatory (contournable par un administrateur) ou hard-mandatory (bloquant, point).

L'estimation des coûts

Sur les principaux clouds, la plateforme estime avant l'apply combien le changement va ajouter (ou retirer) à la facture mensuelle. Et comme cette estimation est accessible aux policies, on peut écrire une règle qui bloque toute modification ajoutant plus de X euros par mois sans validation.

Les équipes et les droits

Les permissions se gèrent par équipe et par workspace (ou par projet). Un schéma courant :

l'équipe de développement peut lancer un plan en production, lire les sorties, mais pas appliquer ;
l'équipe plateforme valide les apply en production ;
l'authentification passe par le SSO de l'entreprise (SAML), et les équipes peuvent être synchronisées depuis l'annuaire.

Le registre privé de modules

Vous vous souvenez du module Vault construit dans l'article précédent ? On le publie dans le registre privé de l'organisation. Chaque nouvelle version est publiée automatiquement à partir d'un tag Git (v1.3.0), avec sa documentation générée depuis le README et les variables. Toute l'entreprise retrouve ainsi les modules validés en un seul endroit, au lieu de copier des dossiers d'un dépôt à l'autre.

module "vault_shop" {
  source  = "tfe.mon-entreprise.fr/mon-entreprise/vault-app/vault"   # app.terraform.io/... sur HCP Terraform
  version = "~> 1.3"
  # ...
}

Garder la ligne de commande

Vous préférez votre terminal ? Le workflow CLI reste disponible :

terraform {
  cloud {
    hostname     = "tfe.mon-entreprise.fr"   # omis pour HCP Terraform
    organization = "mon-entreprise"
    workspaces {
      name = "reseau-dev"
    }
  }
}

terraform login tfe.mon-entreprise.fr
terraform plan    # s'exécute à distance, la sortie s'affiche dans votre terminal

Vous gardez vos habitudes, mais l'exécution, le state et l'historique sont centralisés.

Niveau expert

Run triggers et partage d'outputs

Les run triggers relient les workspaces entre eux : quand reseau-prod est appliqué, app-boutique-prod relance automatiquement un plan. Et grâce à la data source tfe_outputs, le workspace applicatif lit directement les identifiants de sous-réseaux exposés par le workspace réseau, sans les recopier à la main.

Health assessments

À intervalles réguliers, la plateforme compare la réalité au code et vous prévient au moindre drift. C'est l'automatisation du réflexe « lancer un plan de temps en temps pour voir si quelqu'un a touché à quelque chose à la main ».

Les agents pour les réseaux privés

Votre infrastructure est dans un réseau fermé (un vSphere interne, un datacenter sans accès entrant) ? On installe un agent à l'intérieur. Il se connecte en sortant vers la plateforme, récupère les runs en attente et les exécute sur place. Aucun port à ouvrir dans le pare-feu.

Les bonnes pratiques que je recommande

Un workspace par composant et par environnement, plutôt qu'un énorme workspace pour tout. Des plans plus rapides, un rayon d'impact limité, des droits plus fins.
Des identifiants temporaires grâce aux dynamic provider credentials (OIDC) : la plateforme obtient des identifiants à courte durée de vie auprès d'AWS, Azure, GCP ou Vault pour chaque run. Plus aucune clé statique stockée.
Gérer la plateforme avec Terraform : le provider tfe permet de décrire les workspaces, équipes, variables et policies en code. La configuration de l'outil d'IaC… en IaC.
Des policies d'abord en advisory, le temps de mesurer leur impact, avant de les passer en bloquant.

À retenir

Un workspace par infrastructure, avec son state et ses variables. Chaque changement passe par un plan visible dans la pull request, des règles de sécurité, une estimation de coût, puis une validation. Et les modules se partagent dans un registre privé.

Ce cours clôt ma série Terraform : les bases dans « Terraform expliqué de A à Z », puis la création d'un module avec l'exemple de Vault, et enfin le passage à l'échelle avec Terraform Enterprise. Côté configuration de serveurs, l'équivalent pour Ansible s'appelle Ansible Tower, et c'est le sujet d'un autre article.