L’Infrastructure as Code (IaC) s’est imposée comme une discipline incontournable pour les organisations qui gèrent des parcs de ressources cloud ou hybrides à grande échelle. Terraform (HashiCorp) et son fork communautaire OpenTofu ont acquis une position dominante dans cet écosystème, portés par leur modèle déclaratif et leur catalogue de providers couvrant les trois hyperscalers majeurs (AWS, Azure, GCP), les environnements on-premise (VMware, Nutanix) et les services tiers (Datadog, PagerDuty, Vault). Pour les équipes DSI et RSSI, l’enjeu dépasse la simple automatisation du provisioning : il s’agit d’industrialiser la gouvernance, la traçabilité et la sécurité de l’infrastructure elle-même.
Principes fondamentaux de Terraform et d’OpenTofu
Terraform décrit l’état souhaité de l’infrastructure dans des fichiers HCL (HashiCorp Configuration Language). Le moteur de planification calcule le delta entre l’état actuel (lu depuis le state) et l’état cible, puis génère un plan d’exécution que l’opérateur valide avant application. Ce cycle plan/apply est la pierre angulaire du modèle IaC déclaratif.
OpenTofu, hébergé par la Linux Foundation, est né en septembre 2023 après la décision de HashiCorp de passer Terraform sous licence Business Source License (BSL 1.1), incompatible avec les projets open source. OpenTofu maintient la compatibilité syntaxique avec Terraform 1.x et publie des versions indépendantes, avec des fonctionnalités propres à partir de la version 1.7 (chiffrement natif du state, notamment). Pour les organisations soumises à des politiques d’achat open source strictes ou cherchant à éviter une dépendance éditeur, OpenTofu constitue une alternative crédible et activement maintenue.
Les concepts structurants à maîtriser pour une mise en oeuvre industrielle sont les suivants :
- Provider : connecteur vers une API cible (AWS, Azure, Kubernetes), versionné dans le bloc
required_providers - Resource : unité de base représentant un composant d’infrastructure (instance, bucket, règle de pare-feu)
- Module : ensemble réutilisable de resources encapsulant un pattern métier (module VPC, module cluster EKS)
- State : fichier JSON contenant la représentation réelle de l’infrastructure gérée, point critique de sécurité
- Lock file : fichier
.terraform.lock.hclversionné dans Git, qui épingle les versions exactes des providers pour garantir la reproductibilité et prévenir les attaques de type dependency confusion - Workspace : isolation logique du state pour gérer plusieurs environnements depuis le même code base
Gestion du state : le point critique de sécurité
Le fichier terraform.tfstate est souvent sous-estimé dans les analyses de risques. Il contient l’intégralité des métadonnées des ressources gérées et, selon les providers, des valeurs sensibles en clair : mots de passe de bases de données, clés d’accès, certificats. Un state compromis équivaut à une cartographie complète et exploitable de l’infrastructure.
Les pratiques obligatoires en production sont les suivantes :
| Pratique | AWS | Azure | GCP |
|---|---|---|---|
| Backend distant chiffré | S3 + SSE-KMS | Azure Blob Storage + CMK | GCS + CMEK |
| Verrouillage concurrent | DynamoDB (table lock) | Blob lease natif | GCS object locking |
| Contrôle d’accès | IAM policies granulaires | Azure RBAC | IAM + Conditions |
| Versioning du state | S3 Versioning | Blob Versioning | GCS Versioning |
| Audit des accès | CloudTrail | Azure Monitor / Defender | Cloud Audit Logs |
Le state ne doit jamais être commité dans un dépôt Git, y compris privé. La présence de secrets dans des logs CI/CD ou des artefacts de build constitue un vecteur d’exfiltration documenté. L’ANSSI recommande dans ses guides cloud la séparation stricte entre les artefacts de déploiement et les secrets d’infrastructure.
Structurer les modules pour la réutilisabilité et la gouvernance
Un code Terraform non structuré produit rapidement de la dette technique et des risques opérationnels : duplication des configurations de sécurité, dérive de conformité entre environnements, impossibilité d’auditer les changements de surface d’attaque. L’approche modulaire impose une discipline qui sert directement les objectifs de gouvernance.
La structure recommandée pour un dépôt d’infrastructure d’entreprise est la suivante :
infra/
├── modules/
│ ├── network/ # VPC, subnets, security groups
│ ├── compute/ # Instances, ASG, Fargate tasks
│ ├── database/ # RDS, managed services
│ └── iam/ # Roles, policies, OIDC federation
├── environments/
│ ├── dev/
│ ├── staging/
│ └── prod/
└── shared/ # DNS, state backend, monitoringCette séparation permet d’appliquer des politiques de revue différenciées (approbation DSI/RSSI obligatoire pour les modifications du module iam ou network en production) et de tester les changements de modules sur des environnements non-critiques avant promotion.
La validation statique du code avant tout apply est non-négociable : terraform validate pour la syntaxe, terraform fmt --check pour le formatage, et des outils d’analyse de sécurité comme Checkov (Bridgecrew/Palo Alto Networks) ou Trivy en mode IaC (qui a absorbé les règles de l’ancien tfsec, désormais archivé) permettent de détecter automatiquement les configurations non conformes aux CIS Benchmarks AWS/Azure/GCP avant qu’elles n’atteignent un environnement réel.
Pipeline GitOps : plan en PR, apply sur merge
L’approche GitOps appliquée à l’IaC transforme chaque changement d’infrastructure en une demande de fusion (pull request) soumise à revue. Le pipeline CI exécute automatiquement terraform plan et poste le résultat en commentaire de la PR. L’équipe valide le plan (ajout de ressources, modifications, destructions potentielles) avant d’approuver la fusion. Sur le merge vers la branche principale, le pipeline exécute terraform apply.
Ce workflow produit une piste d’audit complète et horodatée de chaque changement d’infrastructure, répondant directement aux exigences de traçabilité de NIS2 (directive UE 2022/2555) pour les entités essentielles et importantes, et de DORA (règlement UE 2022/2554) pour la résilience opérationnelle du secteur financier.
Un point de vigilance majeur concerne les credentials utilisés par le pipeline CI/CD. Les clés d’accès longue durée stockées comme secrets CI sont à proscrire. L’alternative recommandée est la fédération d’identité via OIDC (OpenID Connect) : GitHub Actions, GitLab CI et les principaux systèmes CI supportent la génération de tokens éphémères reconnus directement par AWS (AssumeRoleWithWebIdentity), Azure (Workload Identity Federation) et GCP (Workload Identity). Le rôle assumé ne persiste que le temps du job et n’expose aucune clé statique.
Sécurité du code IaC : des gardes-fous automatisés
L’industrialisation de l’IaC exige des contrôles de sécurité intégrés au pipeline, pas uniquement documentés dans une politique. Plusieurs niveaux de défense sont combinables :
Analyse statique avant apply : des outils comme Checkov ou Trivy en mode IaC détectent les mauvaises configurations (bucket S3 public, groupe de sécurité autorisant 0.0.0.0/0 sur le port 22, chiffrement désactivé sur un volume EBS) et bloquent le pipeline avant tout déploiement.
Politiques as Code (OPA/Sentinel) : Open Policy Agent (OPA) permet d’écrire des politiques de conformité en Rego appliquées au plan Terraform avant l’apply. Ces politiques peuvent imposer des règles métier : toute resource doit avoir un tag owner, aucune instance ne peut être déployée dans une région non approuvée, les instances de base de données doivent avoir le chiffrement au repos activé.
Drift detection : la dérive de configuration (modification manuelle d’une ressource hors du cycle IaC) est un risque opérationnel et de sécurité. Des pipelines de détection de drift exécutent terraform plan en lecture seule sur un calendrier régulier et alertent l’équipe dès qu’un écart est détecté entre le state et la réalité. Le CNCF Landscape référence plusieurs outils natifs pour ce cas d’usage dans la catégorie provisioning.
Gouvernance multi-cloud et conformité continue
Pour les organisations opérant sur plusieurs hyperscalers ou en environnement hybride, Terraform offre une couche d’abstraction uniforme qui simplifie la gouvernance. Les mêmes patterns de modules, les mêmes pipelines et les mêmes politiques de sécurité s’appliquent quel que soit le provider cible.
La notion de multi-provider dans Terraform repose sur la déclaration de plusieurs blocs provider dans la même configuration, chacun avec ses propres credentials et sa propre région. Les modules peuvent être rendus agnostiques du provider en exposant uniquement les interfaces nécessaires (identifiants de réseau, zones de disponibilité), laissant le choix du provider à la couche d’instanciation.
Pour les RSSI, l’IaC facilite également la conformité continue : les configurations de sécurité (groupes de sécurité, politiques IAM, paramètres de chiffrement) deviennent des artefacts versionnés et auditables. Couplé à des outils de Cloud Security Posture Management (CSPM) qui lisent le state Terraform, il devient possible de démontrer la conformité aux référentiels ANSSI, aux CIS Benchmarks ou aux politiques internes sans audit manuel des consoles cloud.
L’Infrastructure as Code n’est pas seulement un outil d’automatisation : c’est un levier de gouvernance qui permet de rendre l’infrastructure aussi prévisible, testable et auditée que le code applicatif. Pour les DSI et RSSI qui doivent justifier la posture de sécurité de leur parc cloud devant des régulateurs ou des auditeurs, Terraform et OpenTofu offrent une base solide à condition de traiter le state, les credentials et les pipelines avec le même niveau d’exigence que le code de production.