API
Intégrateur Terraform Cloud API : relier configuration, plan, décision et state
Terraform Cloud porte aujourd’hui le nom HCP Terraform. Son API ne se résume pas à déclencher un apply : Dawap relie la demande, le workspace, la configuration version, le plan, les contrôles, la confirmation et la state version finale pour que chaque changement d’infrastructure reste attribuable et reprenable.
APIs, données et infrastructures que nos projets savent connecter
Conception, intégration et maintenance
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
avec alertes
Réponse courte
Un run Terraform n’est fiable que si sa configuration, sa décision et sa state restent liées.
Dawap cadre le mode VCS, API ou CLI, le workspace, la configuration version, le token, les contrôles et la state version attendue. Aucun projet client Terraform Cloud nommé n’est publié : les références visibles plus bas prouvent des garde-fous adjacents, pas une réalisation HCP Terraform.
- Attacher chaque run à une configuration version et à une demande identifiables.
- Vérifier policies, run tasks et droit d’apply avant toute confirmation.
- Clore sur le statut terminal, la state version et l’état réel réconcilié.
Le run comme chaîne de décisions
Entre le commit et la state, aucun maillon ne doit disparaître.
Cette vue de run relie la configuration version au plan réellement contrôlé, à l’approbateur et à la state produite. Le portail peut ainsi afficher une décision, pas seulement un bouton « Apply ».
Machine d’étatRun #tf-2048
API-driven
- 01ConfigurationUploadedprouvé
L’artefact source est corrélé au workspace ID.
- 02PlanPlanned and finishedlisible
Diff et state de référence restent attachés.
- 03ContrôlesPolicy checken revue
Un refus mandatory bloque réellement la confirmation.
- 04ApplyConfirmation attribuéeattendu
Le token autorisé agit sur le plan encore courant.
- 05ClôtureState réconciliéeterminal
Serial, lineage et ressource distante convergent.
Signaux Terraform Cloud
Trois ruptures de chaîne qui rendent un apply impossible à expliquer
Le risque apparaît quand l’artefact, le workspace, le plan approuvé et la state finale ne décrivent plus exactement le même changement.
01
Provenance
Le run ne pointe pas une configuration version démontrée
Le bon workspace peut alors exécuter le mauvais artefact ou la dernière configuration disponible.
02
Décision
L’approbation porte sur un plan déjà périmé
Un changement de state, de variables ou de contrôle impose un nouveau plan, pas un apply forcé.
03
State
Force-cancel clôt l’écran mais pas l’infrastructure
Ressources orphelines, serial incohérent et données sensibles exigent une réconciliation opérée.
Architecture HCP Terraform
Un run créé ne prouve ni le bon plan, ni le droit d’appliquer, ni le bon état distant
Le workflow API-driven délègue à votre outil l’origine et l’upload de la configuration. HCP Terraform exécute ensuite une machine d’état avec files, contrôles et verrous. L’intégration doit conserver la relation exacte entre ces objets au lieu de résumer le parcours à un bouton apply.
Workspace comme frontière
Fixer organization, project, workspace ID, execution mode, working directory, version Terraform, variable sets et droits. Un nom ressemblant ne suffit pas à identifier la cible.
Configuration version
Créer la version, envoyer le tar.gz à son upload URL et conserver son ID. L’URL pré-signée est un secret temporaire : elle ne doit pas finir dans les logs ou tickets.
Token adapté à l’action
Un team token convient aux plans et applies de CI selon ses droits ; un organization token administre équipes et workspaces mais ne peut pas exécuter plans et applies.
Run comme machine d’état
Suivre pending, plan, checks, confirmation, apply et état terminal. Un plan-only est spéculatif et ne peut pas être appliqué ; un run 201 n’est qu’une création.
Policies et run tasks
Nommer stage pre/post-plan ou pre/post-apply, résultat, enforcement advisory ou mandatory, timeout, override autorisé et décision humaine avant de continuer.
State et verrou
Contrôler state serial, lineage, statut et resources-processed. Distinguer lock, unlock, cancel et force-cancel ; une sortie forcée peut laisser state perdue ou ressources orphelines.
Méthode
On dessine d’abord la chaîne demande–configuration–state sur un seul workspace
Le pilote refuse les noms ambigus, épingle configuration et run, vérifie un contrôle bloquant, sépare plan et apply, puis compare state et ressource réelle. Les chemins 403, 409, pending, cancel et fuite simulée sont traités avant toute généralisation.
Décision 1
Workspace et configuration sans ambiguïté
Décision 2
Plan distinct de l’apply
Décision 3
Permissions du bot réellement bornées
Décision 4
Contrôles et overrides attribuables
Premier lot Terraform Cloud
Prouver un run complet sur un workspace non critique.
On part d’une demande autorisée, on charge une configuration identifiable, on obtient un plan lisible, on force un refus attendu, puis on confirme l’apply et on réconcilie la state version avec la ressource créée.
Entrée : demande et configuration
Sortie : apply réconcilié
Suite : étendre par workspace
Le périmètre à définir
Matrice organization × project × workspace × environnement × owner × version Terraform.
Chaîne configuration version × run × plan × policy/run task × confirmation × apply × state version.
Token user, team ou organization, permissions effectives, variables, state, agents et dépendances provider.
Recette 401, 403, 409, plan-only, policy failed, run pending, lock, cancel, force-cancel et reprise.
Recette Terraform Cloud
Trois contre-tests qui révèlent les faux succès IaC
La recette cible la provenance de la configuration, le passage irréversible du plan à l’apply et les frontières de sécurité que les libellés sensitive ou force-cancel ne garantissent pas.
Le run part dans le bon organization mais avec la mauvaise configuration version
Créer un run sans configuration version explicite peut réutiliser la version la plus récemment utilisée du workspace. Un upload API peut aussi déclencher automatiquement un run selon le workflow ; la réponse 201 ne prouve ni la provenance ni le plan produit.
- Entrée
- Demande, organization, project, workspace ID, configuration version ID, upload status, source commit/artefact, working directory, Terraform version, run source et run ID.
- Sortie
- Contrat qui épingle la configuration version attendue, refuse un workspace ambigu et rapproche checksum, commit, run et plan avant toute confirmation.
- Décision
- Ne jamais appliquer un plan dont la configuration, le workspace ou le commit source ne sont pas démontrés.
Le plan est vert, mais la state change avant la confirmation
Un plan-only ne peut pas être appliqué. Un saved plan ne devient courant qu’à sa confirmation et HCP Terraform peut l’écarter si la state du workspace change avant apply. Un lock bloque les applies, mais autorise certains plans sans effet.
- Entrée
- Run operation, plan ID, state version de référence, is-confirmable, status, policy checks, run tasks, lock owner/reason, file d’attente, apply ID et state version finale.
- Sortie
- Gate de confirmation qui relit run, plan, contrôles, verrou et state de référence, puis refuse une décision périmée au lieu de forcer l’exécution.
- Décision
- Replanifier quand la state ou la configuration a changé ; ne pas transformer force-execute en chemin nominal.
Une variable sensitive est masquée, puis une valeur apparaît dans state ou dans les logs
Sensitive rend la valeur non lisible dans l’interface et l’API Variables, mais Terraform peut toujours l’utiliser pendant plan/apply ; state et providers peuvent porter des données sensibles, et la redaction des logs reste une mitigation. Un force-cancel peut en plus perdre de la state ou orpheliner des ressources.
- Entrée
- Variable source, variable set, flags sensitive/ephemeral, token, droits de lecture, plan/state access, run task, logs, provider, cancel signal, force-cancel, objets distants et dernière state saine.
- Sortie
- Fixture de fuite, tests de masquage, politique de logs, accès state minimal, procédure cancel avant force-cancel et réconciliation import/remove documentée.
- Décision
- Traiter state, plan, logs et upload URLs comme sensibles ; réserver force-cancel au dernier recours avec contrôle manuel.
Connexions complémentaires
Relier les autres outils de votre SI
Ces prestations couvrent les connexions avec les outils qui interviennent en amont ou en aval de vos flux.
Notre intervention
Ce que l’on sécurise avec Terraform Cloud
Provenance démontrée
Demande, artefact, configuration version, workspace et run restent corrélés.
Décision explicite
Plan, policies, run tasks, override, approbateur et droit d’apply sont relus.
État réconcilié
Apply, state serial/lineage, ressource distante, incident et reprise ne sont pas confondus.
Pour Branchassist, passer du SSO historique à Keycloak ne devait pas transférer aveuglément les autorisations. Dawap a séparé la connexion externe des droits internes : échange du code, contrôle de l’utilisateur actif, rôles Symfony, accès par ressource, révocation des jetons et trace des connexions. Une migration IAM ancrée dans l’application métier.
Webhook, polling et rattrapage ne servent pas le même objectif : l’un pousse le signal, l’autre contrôle la reprise. Cette carte montre comment tenir commandes, stocks et tickets sans confondre latence, quota et cohérence métier, tout en gardant un flux lisible pour le support et pour le run. Un vrai repère pour le run.
Audit trail API garde la preuve utile quand le support, la conformité et le run doivent reconstituer une action sans fouiller tout le système. La trace doit montrer qui a fait quoi, quand, sur quel endpoint et avec quel contexte, puis rester exploitable après incident. Il reste utile quand un incident tombe après coup.
Questions fréquentes
Questions fréquentes sur l’intégration Terraform Cloud API
Questions fréquentes sur Terraform Cloud API, HCP Terraform, configuration versions, runs, tokens, policies, state et reprise.
01Terraform Cloud et HCP Terraform désignent-ils le même service ?
HCP Terraform est le nom actuel du service historiquement appelé Terraform Cloud. Nous vérifions les objets et les permissions de votre environnement HCP Terraform avant de définir les échanges avec le SI.
02Comment fonctionne un run API-driven ?
Votre outil crée une configuration version, récupère une upload URL, envoie le tar.gz puis suit le run associé. L’upload peut mettre un run en file. Sans auto-apply, un acteur ou token autorisé confirme ensuite l’apply ; chaque ID et statut doit être corrélé.
03Quel token utiliser pour automatiser plans et applies ?
Un team token est prévu pour les pipelines CI/CD, dans la limite des permissions de son équipe. Un user token agit pour son utilisateur. Un organization token administre notamment équipes et workspaces, mais ne peut pas exécuter plans et applies. On choisit le token le moins privilégié compatible avec le lot.
04Une variable sensitive est-elle absente du plan, des logs et de la state ?
Non. Le marquage sensitive empêche sa lecture dans l’interface et via l’API Variables, mais Terraform peut l’utiliser pendant plan/apply. La state peut contenir des données sensibles et la redaction des logs ne constitue pas une frontière absolue. Accès, fixtures de fuite et rotation restent nécessaires.
05Quand peut-on confirmer ou rejouer un apply ?
Seulement après avoir relu le run, la configuration version, le plan, les contrôles, le verrou et la state de référence. Un plan-only ne s’applique pas. Si configuration ou state a changé, on produit un nouveau plan ; force-execute et force-cancel restent des procédures exceptionnelles.
06Quel premier lot Terraform Cloud recommandez-vous ?
Un workspace non critique et une demande cataloguée : configuration version identifiable, plan, contrôle mandatory, approbation, apply, state version et ressource réconciliée. Le lot inclut tests 403/409, lock, cancel, fuite simulée, reprise et owner de support.
API cloud & infrastructure
Vous voulez connecter Terraform Cloud sans réduire le run à un bouton apply ?
On peut cadrer un premier workflow HCP Terraform, livrer son intégration et rendre chaque configuration, décision, changement de state et reprise vérifiable.
Cadrer mon workflow Terraform Cloud