Gains :
- Capacité à comprendre le concept IaC et le cycle de travail de Terraform (initialisation, planification, application, état, module) et à demander à l'intelligence artificielle de produire des brouillons HCL sûrs.
- Possibilité de vérifier chaque changement avec un plan avant de l'appliquer et de détecter les lignes de destruction/remplacement inattendues
- Capacité à appliquer les principes consistant à garder les secrets hors du code, à conserver l'état en toute sécurité et à minimiser les autorisations IAM
Autrefois, configurer un serveur consistait à cliquer sur un panneau cloud : créer une machine virtuelle, configurer le réseau, ajouter la règle de sécurité. Cette méthode était lente, sujette aux erreurs et unique : il était presque impossible de configurer le même environnement une seconde fois. Aujourd’hui, l’infrastructure est gérée sous forme de code. IaC (Infrastructure as Code) est une approche permettant de décrire les ressources cloud telles que les serveurs, les réseaux et les bases de données dans des fichiers texte plutôt que manuellement. Ces fichiers se trouvent dans le contrôle de version (Git) ; Vous pouvez voir qui a changé quoi, quand et quoi ; Vous pouvez configurer la même infrastructure plusieurs fois, exactement de la même manière, avec une seule commande.
L'outil IaC le plus courant est Terraform. Terraform prend les définitions que vous écrivez dans un langage lisible appelé HCL (HashiCorp Configuration Language — le langage de configuration de Terraform), les traduit dans l'API du fournisseur de cloud (AWS, Azure, GCP) et crée les ressources. L’IA connaît très bien HCL et produit rapidement des blocs complexes. Mais en IaC, le coût d’une erreur est élevé : une mauvaise définition peut anéantir toute une base de données de production. C'est pourquoi la règle d'or dans Terraform est de voir chaque changement avec un « plan » avant de le mettre en œuvre.
L'environnement d'exécution de Terraform
Terraform fonctionne avec trois commandes de base — les connaître est une condition préalable pour contrôler la sortie de l'IA :
- `terraform init` : démarre le projet, télécharge les plugins fournisseurs nécessaires.
- « plan terraform » : compare la situation actuelle avec la situation souhaitée et montre ce qu'il faut ajouter, quoi changer, quoi supprimer. N'implémente rien. Il s’agit de l’étape de sécurité la plus critique.
- `terraform apply` : applique réellement le plan, en créant/modifiant des ressources.
De plus, deux concepts sont essentiels. État (fichier d'état) : il s'agit du fichier dans lequel Terraform conserve l'état actuel des ressources qu'il gère ; Il est généralement stocké dans un entrepôt éloigné et verrouillé afin que deux personnes ne puissent pas le modifier ou le détruire en même temps. Module : package de configuration réutilisable ; Par exemple, vous pouvez utiliser le module « mettre en place un réseau » dans de nombreux projets.
Astuce : Le signe le plus dangereux dans une sortie Terraform est la destruction ou -/+ (remplacer) des lignes dans la sortie du plan. Cela signifie que la ressource sera supprimée. Si vous voyez une destruction inattendue dans un plan, ne postulez jamais, comprenez d'abord pourquoi elle est apparue.
Étape par étape : écrire IaC avec l'IA
- Clarifier l’infrastructure souhaitée. Soyez concret comme "un VPC, deux sous-réseaux, un groupe de sécurité et un t3.micro EC2 sur eu-central-1".
- Spécifiez le fournisseur et la version. Quel cloud, quelle version de Terraform et du fournisseur ? Si vous ne spécifiez pas de version, AI peut renvoyer une syntaxe obsolète/incompatible.
- Faites produire le projet HCL. Demandez également des variables et des sorties.
- Sortez Secret. Les valeurs telles que les mots de passe et les clés doivent être placées dans le coffre-fort variable et secret, et non dans le code.
- Exécutez `init` + `plan`. Lire le résultat du plan ligne par ligne ; Recherchez les suppressions inattendues.
- Commencez petit, mettez en œuvre progressivement. Appliquez-le d’abord dans un compte/environnement de test isolé.
Sécurité : risques spécifiques à IaC
IaC est aussi risqué que puissant. Trois points critiques :
- Il y a un secret dans le dossier de l'État. L'état Terraform conserve parfois des valeurs sensibles, telles que les mots de passe de base de données, en texte brut. Ne placez jamais l'État dans un référentiel public ; Utilisez un backend distant crypté et à accès restreint.
- N'intégrez pas de secrets dans HCL. Des lignes comme password="prod123" sont écrites de manière permanente dans l'historique Git. Utilisez plutôt une variable et donnez la valeur au moment de l'exécution à partir de la variable d'environnement (TF_VAR_...) ou du coffre-fort secret.
- Autorisation IAM très large. L'IA produit parfois des blocs comme Action : "*" (tout autoriser) pour "le faire fonctionner". Il s'agit d'une vulnérabilité ; restreindre l’autorisation au minimum requis.
Attention : Une fois qu'un secret entre dans l'historique Git, il reste dans le passé et peut être compromis, même si vous supprimez le fichier. Si vous commettez par erreur, annulez et faites immédiatement pivoter le secret ; La simple suppression ne suffit pas.
Tableau des signes du plan risqué
Impression du plan
Signification
que faire
+créer
Une nouvelle ressource sera ajoutée
Généralement sûr, à revoir cependant
~ mise à jour sur place
La source changera sur place
Vérifier l'impact (y aura-t-il une panne ?)
-/+ remplacer
Sera supprimé et recréé
ATTENTION : une perte de données peut survenir
- détruire
La ressource sera détruite
STOP : ne postulez jamais si vous ne vous y attendez pas
trois mini-cases
Cas 1 — 2 jours de travail en 3 heures. Une équipe allait écrire Terraform pour mettre en place un nouvel environnement de test (VPC, sous-réseaux, base de données RDS, cluster ECS) mais elle venait de migrer vers HCL. Ils ont décrit l'architecture et les versions de l'IA et produit un plan modulaire. Ils ont vérifié chaque module avec le plan et l'ont mis en service en 3 heures ; Cela leur prendrait deux jours d’essais et d’erreurs manuels.
Cas 2 : le plan a été supprimé. Un ingénieur a exécuté un plan sans appliquer de code de mise à jour généré par l'IA. La sortie contenait -/+ replace pour la base de données de production – l'IA a tenté de remplacer un champ non remplaçable, ce qui impliquait la suppression et la recréation de la base de données. L'ingénieur a arrêté l'application et a modifié la modification en faveur de la méthode sûre. L’habitude de planifier a évité un désastre.
Cas 3 : fuite secrète enfouie. Un junior, YZ a émis db_password = "S3cret!" Il a engagé la ligne telle quelle et l'a poussée. Pris dans la révision du code ; Le mot de passe a été immédiatement annulé et modifié, la valeur a été déplacée vers une variable et alimentée depuis le coffre-fort secret. Leçon : Il n'y a jamais de secrets en clair dans HCL.
Quatre modèles copiables
1) Génération d'un projet d'infrastructure :
Écrivez l'infrastructure suivante sur [CLOUD : AWS] avec Terraform (version ~> 1.7) : [SOURCE LIST]. Région [X]. Règles : - Rendre toutes les valeurs sensibles variables, ne les intégrez pas dans HCL. Donnez du code de manière modulaire et avec des explications.
2) Interprétation des résultats du plan :
Analysez le résultat du « plan de terraformation » ci-dessous. Indiquez-moi : (1) quelles ressources ont été ajoutées/modifiées/SUPPRIMÉES, (2) les lignes présentant un risque de perte ou d'interruption de données, (3) 3 questions que je devrais poser avant de postuler. Plan : [SORTIE]
3) Examinez la HCL existante pour la sécurité :
Vérifiez le code Terraform suivant pour la sécurité : secret intégré, autorisation IAM trop large, règle de réseau ouvert (0.0.0.0/0), stockage non chiffré ? Écrivez chaque constatation par ordre d’importance et de correction. Code : [HCL]
4) Convertissez le code répétitif en module :
Convertissez le code Terraform répétitif suivant en un module réutilisable : quelles valeurs doivent être des variables, quelle doit être l'interface du module ? Montrez également un exemple d'utilisation. Code : [HCL]
Invite faible/Invite forte
Faible : "Créez une base de données avec Terraform."
Résultat : on ne sait pas quel cloud, quel moteur, quelle version, chiffré ou non ; Avec la syntaxe héritée, l’IA peut fournir un exemple accessible au public qui intègre le mot de passe dans le code.
Strong : "Créez une instance RDS PostgreSQL 15 sur AWS avec Terraform ~> 1.7. Créez la variable de mot de passe, ne l'intégrez pas dans le code. Le stockage est crypté, accessible uniquement à partir d'un sous-réseau privé, non public. Corrigez la version du fournisseur. Renvoyez le point de terminaison en sortie. "
Différence : la deuxième invite donne le moteur, la version, le cryptage, la contrainte réseau et la règle secrète — la sortie est sécurisée et proche de la production.
Erreurs courantes
- « Postuler » sans faire de « plan ». L'erreur la plus coûteuse en IaC ; planifiez toujours en premier.
- Intégration du secret dans HCL. Crée une fuite permanente dans l’historique de Git.
- État de stockage non sécurisé. Un État public non chiffré et déverrouillé est un désastre.
- Ne corrige pas la version. Utiliser le fournisseur sans spécifier de version entraînera des échecs soudains à l'avenir.
- *`Action : autorisation large telle que ""`.** Viole le principe du moindre privilège.
- Ignorer la « destruction » inattendue. Application des lignes de suppression dans le Plan sans remise en question.
En résumé
IaC transforme l'infrastructure en code reproductible, versionnable et auditable ; L'outil le plus courant est Terraform. AI produit rapidement des stubs HCL, mais vous devez fournir la version, les détails spécifiques au cloud et les règles de sécurité. La règle infaillible dans Terraform : voir chaque changement avec un plan, interroger les suppressions inattendues, garder les secrets loin du code et garder l'état en sécurité. Les lignes de destruction et de remplacement dans une sortie de plan sont les endroits qui doivent être lus le plus attentivement.
Tâche de candidature
Demandez à l'IA de générer une petite infrastructure (par exemple, un compartiment de stockage et une politique d'accès) à l'aide du modèle « Générer un croquis d'infrastructure » ci-dessus. Ensuite : (1) demandez au modèle de « vérification » de vérifier les autorisations secrètes ou * intégrées dans le code ; (2) si possible, exécutez init + plan dans un compte de test et lisez le résultat du plan avec le modèle « interprétation du plan » ; (3) notez toute suppression/modification inattendue.
liste de contrôle
- [ ] J'ai ajouté des contraintes de cloud, de version Terraform/fournisseur et de chiffrement/réseau à mon invite.
- [ ] Il n'y a pas de secret en clair dans le code ; valeurs de précision variables.
- [ ] J'ai réduit IAM/autorisations à des autorisations minimales, * Je ne l'ai pas utilisé.
- [ ] J'ai exécuté le plan avant d'appliquer et lu le résultat ligne par ligne.
- [ ] J'ai vérifié qu'il n'y a pas de destruction/remplacement inattendu dans le plan.
- [ ] Je suis sûr que l'état est conservé dans un backend crypté, verrouillé et restreint.