Terraform Associate #7 — HCP Terraform

Suite de ma série sur la certification Terraform Associate, après le module sur le state. Dernier objectif de l’exam guide, “Understand HCP Terraform capabilities” : cet article couvre les workspaces, l’intégration VCS, le registre privé, Sentinel/OPA et l’exécution en automation.

Qu’est-ce que HCP Terraform

HCP Terraform (anciennement Terraform Cloud) est le service managé de HashiCorp : state distant, locking, runs plan/apply centralisés, et couche de gouvernance en plus du CLI open source.

Workspaces : CLI vs HCP Terraform

Le mot “workspace” désigne deux choses différentes selon le contexte :

	Workspace CLI (OSS)	Workspace HCP Terraform
Portée	Plusieurs états pour une même configuration locale (`terraform workspace new`)	Unité complète : configuration + variables + state + historique des runs
State	Un fichier par workspace, même backend	State propre à chaque workspace
Isolation	Faible, même répertoire de code	Forte, généralement un repo/dossier ↔ un workspace

Un workspace HCP Terraform correspond en général à un environnement (dev/staging/prod) ou un composant d’infrastructure, chacun avec ses propres variables et son propre historique.

Les workspaces peuvent partager des informations entre eux via des outputs racine.
Un workspace utilisant l’exécution distante peut accéder aux outputs d’un autre workspace via une source de données terraform_remote_state, sous réserve des contrôles d’accès par workspace.
Des run triggers workspace-à-workspace permettent de faire réagir automatiquement un workspace en aval quand ses dépendances changent.

Intégration VCS

Un workspace peut être connecté à un dépôt Git (GitHub, GitLab, Bitbucket…). Chaque push ou pull request déclenche automatiquement un run.

Génère un plan en preview sur les pull requests, avant merge.
Déclenche un apply sur push vers la branche configurée (selon le mode d’apply du workspace).
Évite d’exécuter Terraform depuis un poste local : le run s’exécute sur l’infrastructure HCP Terraform.

Registre privé

En plus du Terraform Registry public, HCP Terraform propose un registre privé pour publier des modules et des providers internes, avec la même syntaxe source = "app.terraform.io/<org>/<nom>/<provider>" que le registre public.

Estimation des coûts

HCP Terraform peut estimer le coût mensuel des ressources créées, modifiées ou détruites par un plan, pour les providers supportés (AWS, Azure, GCP).

L’estimation apparaît directement dans le run, avant l’apply.
Elle peut être utilisée dans une policy Sentinel (ex. bloquer un plan si le delta de coût dépasse un seuil).
Elle reste une estimation basée sur le pricing public du provider, pas une facture réelle (remises, réservations… non prises en compte).

Sentinel et OPA

Sentinel (propriétaire HashiCorp) et Open Policy Agent (OPA) permettent d’appliquer du policy as code : des règles évaluées automatiquement entre le plan et l’apply, pour bloquer un changement qui ne respecte pas une politique organisationnelle.

# exemple de règle Sentinel
main = rule {
  all tfplan.resources.aws_instance as _, instances {
    all instances as _, r {
      r.applied.instance_type in ["t3.micro", "t3.small"]
    }
  }
}

Advisory : avertit sans bloquer.
Soft mandatory : bloque, mais un utilisateur autorisé peut passer outre.
Hard mandatory : bloque sans possibilité de contournement.

Cas d’usage typiques : imposer des tags obligatoires, restreindre les types d’instance autorisés, interdire l’ouverture de ports sensibles.

Run tasks

Les run tasks intègrent un service tiers (scan de sécurité, coût, conformité…) dans le cycle de vie d’un run, à un stade précis (post-plan, pre-apply, post-apply).

HCP Terraform envoie les détails du run à l’endpoint du service tiers via une API webhook.
Le service répond avec un statut passed ou failed.
Comme Sentinel/OPA, la sévérité peut être advisory (informatif) ou mandatory (bloque l’apply si le check échoue).

Contrairement à Sentinel/OPA qui évalue localement le plan avec des règles écrites en Sentinel ou Rego, un run task délègue la vérification à un outil externe (ex. Snyk, Bridgecrew, Infracost).

RBAC

HCP Terraform gère les permissions à deux niveaux :

Niveau organisation : rôles Owner, ou permissions personnalisées (gestion des membres, des teams, des paramètres).
Niveau workspace : accès par team, avec des permissions fixes (Read, Plan, Write, Admin) ou personnalisées (ex. autoriser l’apply sans donner accès aux variables sensibles).

Les teams regroupent des utilisateurs et se voient assigner des permissions par workspace, ce qui permet par exemple de restreindre l’apply en prod à une team dédiée.

Run triggers et notifications

Les run triggers permettent de chaîner des workspaces : un apply réussi sur un workspace peut déclencher automatiquement un run sur un autre (ex. réseau → applicatif).
Les notifications (Slack, email, webhook générique) informent des événements d’un workspace (run créé, en attente, terminé, erreur).
Les run triggers sont destinés aux workspaces qui dépendent d’informations ou d’infrastructure produites par d’autres workspaces.
Un run déclenché par un run trigger n’est pas auto-appliqué, sauf si l’option “Auto-apply run triggers” est activée.

Workspaces vs Stacks

HCP Terraform Stacks est une fonctionnalité pour orchestrer plusieurs composants d’infrastructure liés comme une seule unité :

Workspace : une configuration, un state, un cycle de vie indépendant. Pour chaîner plusieurs workspaces (ex. réseau → applicatif), il faut des run triggers ou de l’orchestration externe.
Stack : regroupe plusieurs composants (chacun avec son propre state) déployés ensemble sur plusieurs environnements ou régions, avec un ordonnancement natif des dépendances entre composants et une configuration écrite en langage Terraform Stacks (basé sur HCL, fichiers .tfcomponent.hcl).

En résumé, un Stack remplace le pattern “plusieurs workspaces + run triggers” par une orchestration native quand les composants sont fortement couplés.

graph TD
    Org[Organisation] --> Proj[Projet]
    Proj --> WS1[Workspace: réseau]
    Proj --> WS2[Workspace: applicatif]
    Proj --> Stack[Stack]
    Stack --> C1[Composant: state 1]
    Stack --> C2[Composant: state 2]

Health checks

HCP Terraform peut vérifier périodiquement l’état d’un workspace en dehors des runs déclenchés manuellement :

Drift detection : lance un plan régulier pour détecter si l’infrastructure réelle a divergé du state (changement fait hors Terraform).
Continuous validation : réévalue en continu les blocs check de la configuration (ex. certificat encore valide, endpoint toujours joignable) même sans nouveau run.

Ces contrôles remontent des alertes sans forcément déclencher d’apply, ce qui aide à repérer une dérive avant qu’elle ne cause un incident.

Exécution en automation

HCP Terraform peut lancer des runs via trois mécanismes :

VCS-driven : déclenché par un push/PR sur le dépôt connecté (voir ci-dessus).
API-driven : déclenché par un appel à l’API HCP Terraform, utile pour l’intégrer à un pipeline CI/CD externe.
CLI-driven : terraform plan/apply lancés localement, mais exécutés à distance sur HCP Terraform grâce au bloc cloud (voir l’article sur le state).

Dans les trois cas, l’exécution du run (et l’accès aux credentials associés) a lieu sur l’infrastructure HCP Terraform, pas sur le poste ou l’agent qui déclenche l’opération.

Migrer son state vers HCP Terraform

Pour basculer un state existant (local ou backend distant type S3) vers HCP Terraform :

Ajouter un bloc cloud dans la configuration, avec l’organisation et le nom du workspace cible :

terraform {
  cloud {
    organization = "mon-org"
    workspaces {
      name = "mon-workspace"
    }
  }
}

Lancer terraform login pour s’authentifier auprès de HCP Terraform.
Lancer terraform init : Terraform détecte l’ancien backend et propose de migrer le state existant vers le workspace HCP Terraform.
Confirmer la migration : le state est copié, le workspace HCP Terraform en devient la nouvelle source de vérité.

Une fois migré, le mode d’exécution du workspace (remote par défaut, ou local) détermine si les plan/apply s’exécutent sur l’infrastructure HCP Terraform ou toujours en local avec state distant.

Ce que je retiens

Workspace CLI ≠ workspace HCP Terraform : le premier isole un state, le second isole un environnement complet (config, variables, historique).
Sentinel/OPA s’évaluent entre plan et apply : c’est le point de contrôle pour bloquer un changement non conforme avant qu’il ne soit appliqué.
Trois façons de déclencher un run : VCS, API ou CLI, mais l’exécution reste toujours centralisée côté HCP Terraform.

Fin de cette série sur le “learning path” Terraform Associate. La suite consistera à développer un projet pour mettre en application toutes les connaissances acquises avec le learning path.