Gains :
- Capacité à produire du code IaC (Terraform, Ansible) avec l'intelligence artificielle avec les autorisations les plus étroites et les valeurs par défaut sûres et à comprendre l'approche déclarative
- Possibilité d'éviter la perte de données en lisant et en capturant les lignes de suppression et de remplacement forcé avant d'appliquer la sortie du plan/vérification
- Possibilité d'empêcher les fuites de secrets en gardant le fichier d'état crypté, verrouillé dans le backend distant et en divisant les modifications en petites étapes réversibles.
Gestion de l'Infrastructure as Code (IaC) : Terraform, Ansible et Plan Control avec l'IA
Dans le passé, la configuration d'un serveur se faisait à l'aide de clics manuels, de commandes et de notes personnelles ; Le résultat était des serveurs « flocon de neige » irréproductibles que personne ne savait exactement comment configurer. L'Infrastructure as Code (IaC) est l'approche qui met fin à ce chaos : les serveurs, les réseaux, les règles de sécurité ne sont pas définis à la main, mais par des fichiers texte versionnables (code). Lorsque vous exécutez ce code, l'infrastructure est configurée exactement comme vous l'avez écrite : la même, documentée et reproductible à chaque fois. Les outils les plus courants sont Terraform et CloudFormation pour l'infrastructure cloud et Ansible pour la configuration du serveur. Ici, l'IA est très compétente pour écrire, expliquer et réviser ce code IaC. Mais la puissance de l’IaC réside aussi dans son danger : une mauvaise ligne peut anéantir toute une infrastructure ; donc l'IA écrit du code, vous lisez le "plan", l'approuvez et l'exécutez.
Dans cette unité, nous discuterons de l'approche déclarative, de la distinction planifier/appliquer, de la sécurité de l'État et de l'idempotence ; Vous apprendrez la génération IaC avec l'IA et la compétence la plus critique, le « contrôle du plan ».
Penser de manière déclarative : « et si » et non « comment faire »
La plupart des outils IaC sont déclaratifs : vous décrivez l'état final du système ("disons 3 serveurs Web, 1 équilibreur de charge"), l'outil calcule lui-même comment accéder à cet état. Ceci est différent de l'écriture d'un script (« faites ceci, puis faites cela » étape par étape). Le gros avantage de l’approche déclarative est l’idempotence : même si vous exécutez le code dix fois, le résultat est le même, car l’outil vérifie si l’état souhaité existe déjà, et si c’est le cas, il n’y touche pas. N'oubliez pas cette différence lorsque vous écrivez IaC dans l'IA : vous lui faites dire "laissez cette infrastructure dans l'état", et non "exécutez ces commandes".
Planifier/appliquer : garde-corps de sécurité le plus vital
La fonctionnalité vitale de l’IaC est l’étape de planification. Dans Terraform, terraform plan, dans Ansible, le mode --check produit un aperçu de « ce qui changera si je l'applique » avant d'exécuter le code : « 2 ressources seront ajoutées, 1 changera, 0 sera supprimée ». C’est la seule façon de comparer votre intention avec la réalité avant sa mise en œuvre. Règle essentielle : ne postulez jamais sans avoir lu le plan. Recherchez particulièrement les lignes « destroy » ; Si vous voyez « 12 sera supprimé » au lieu de « 1 sera modifié » à cause d'une faute de frappe, le plan vous a sauvé du désastre. Après avoir imprimé le code sur l'IA, demandez-lui de dire "examinez la sortie du plan ligne par ligne avec moi, marquez chaque ligne contenant une suppression/recréation".
Attention : Certaines modifications apportées à Terraform « détruisent et recréent » une ressource plutôt que de « mettre à jour sur place ». Cela signifie une perte de données pour une base de données. Ignorer -/+ ou « remplacement des forces » dans la sortie du plan est l'une des erreurs les plus coûteuses.
Dossier d'État : registre des secrets et de la vérité
Des outils comme Terraform conservent l'état actuel de l'infrastructure qu'ils gèrent dans un fichier d'état. Ce fichier est critique pour deux raisons. Premièrement, il peut contenir des secrets (les mots de passe de la base de données et les clés peuvent tomber en texte clair) ; Par conséquent, ne collez jamais l’état dans un référentiel public ou une IA, conservez-le dans un backend distant crypté et à accès restreint. Deuxièmement, si l’État est corrompu ou perdu, le véhicule perd le lien entre l’infrastructure réelle et l’infrastructure imaginée ; Une sauvegarde de l’état et un mécanisme de verrouillage (serrure qui empêche deux personnes de le briser en même temps) sont donc indispensables.
Étape par étape : sécuriser l'IaC avec l'IA
- Intention de l’État et fournisseur. "2 serveurs sur AWS, avec Terraform, dans cette région, cette taille et un groupe de sécurité." Si le cloud, l'outil et la version sont clairs, l'IA produit une syntaxe correcte.
- Demander les valeurs par défaut de sécurité. "Ouvrez le groupe de sécurité, activez le cryptage, extrayez les secrets d'une variable, accordez l'accès public." L'IA peut générer des échantillons en vrac par défaut.
- Lisez et comprenez le code. Comprenez chaque ressource, chaque autorisation, ligne par ligne. N'appliquez pas une autorisation que vous ne comprenez pas.
- Obtenez un plan et auditez-le. Exécutez plan/--check, examinez la sortie avec AI, marquez les lignes de suppression et de reconstruction.
- Appliquer petit et réversible. Mettez en œuvre un grand changement par petites étapes, pas en une seule fois. Connaissez le chemin du retour à chaque étape.
- Protéger l’État. Utilisez un backend et un verrouillage distants et cryptés ; Jamais de fuite.
trois mini-cases
Cas 1 — Le plan a récupéré une base de données. Un ingénieur souhaitait augmenter la taille d'une base de données avec le code Terraform qu'il produisait avec l'IA. Alors qu'il s'attendait à ce que "1 change" dans la sortie du plan Terraform, il a vu "1 à détruire, 1 à ajouter" - le paramètre qu'il a choisi déclenchait une reconstruction, pas une mise à jour sur place, ce qui signifie que toutes les données seraient supprimées. Le contrôle du plan a stoppé la perte irréversible de données avant sa mise en œuvre.
Cas 2 — Retour d'un défaut de paiement lâche. Une équipe a demandé à l'IA un code de pare-feu. Pour exécuter l'exemple, l'IA a généré une règle simple de 0.0.0.0/0, signifiant « public sur Internet ». L'ingénieur l'a remarqué en lisant le code et a restreint l'accès à la seule plage IP de l'entreprise. Si elle était mise en œuvre sans audit, la base de données serait ouverte à l’ensemble d’Internet.
Cas 3 — Fuite d’état évitée. Un membre junior était sur le point de coller le fichier terraform.tfstate intact dans un outil public pour résoudre un problème Terraform. L'ingénieur principal s'est arrêté : l'état contenait un mot de passe de base de données en texte brut. Au lieu de cela, un résumé déchiffré décrivant le problème a été partagé et l’état a été déplacé vers le backend chiffré distant.
Quatre modèles copiables
1) Génération de ressources IaC (par défaut sécurisé) :
Votre rôle : ingénieur senior en infrastructure cloud. [Cloud, par ex. AWS] pour[outil, par ex. Terraform] génère du code. Objectif : [objectif].Règles de sécurité : accès public (0.0.0.0/0) OUVERT ; commencer avec l'autorisation la plus étroite ; activer le cryptage ; extrayez les secrets dans des variables, ne les intégrez pas dans le code ; Vérifiez les paramètres pouvant conduire à une suppression/recréation. Expliquez chaque source avec un bref commentaire.
2) Planifier l'audit des résultats :
Vous trouverez ci-dessous une sortie [Plan Terraform / Vérification Ansible]. Dites-moi : (1) combien de ressources seront ajoutées/modifiées/supprimées, (2) marquez également les lignes "détruire" ou "forcer le remplacement" qui présentent un risque de perte de données, (3) répertoriez tous les changements qui semblent inattendus ou dangereux. Résultat : [plan]
3) Examen de la sécurité du code IaC :
Examinez le code IaC suivant pour en vérifier la sécurité : (1) y a-t-il un accès/des autorisations trop larges, (2) le cryptage est-il désactivé, (3) y a-t-il des secrets intégrés dans le code, (4) existe-t-il des ressources accessibles au public ? Suggérez une correction pour chaque constatation. Code : [code masqué]
4) Divisez le changement en parties sûres :
Je ne veux pas mettre en œuvre ce grand changement d'infrastructure [explication] d'un seul coup. Décomposez-le en petites étapes indépendantes auxquelles il est facile de revenir. Pour chaque étape : quels changements, à quoi dois-je faire attention dans le plan, comment puis-je l'annuler en cas de problème ?
Invite faible/Invite forte
Invite faible :
Écrivez du code Terraform qui crée un serveur sur AWS.
La région, la taille, la sécurité, le réseau et le cryptage ne sont pas clairs. L’IA produit les paramètres par défaut les plus lâches et les plus explicites – si elle était mise en production, ce serait une vulnérabilité.
Invite puissante :
Votre rôle : ingénieur senior en infrastructure cloud. Définissez un serveur web avec Terraform sur AWS eu-central-1 : t3.small, uniquement à partir de la plage IP de l'entreprise (je le donnerai avec une variable), le port 443 est ouvert, le disque est crypté, pas d'accès public, les labels sont obligatoires. Les secrets sont révélés à la variable. Après le code : Avant de l'implémenter, indiquez-moi les 3 types de lignes auxquels je dois faire attention dans le plan et expliquez le chemin de retour.
Scène
Risque
garde-corps de sécurité
écrire du code
Valeur par défaut lâche (publique)
Autorisation la plus étroite + lecture
planifier/vérifier
Supprimer sans s'en rendre compte
Planifier l'inspection, détruire le marquage
Postuler
Changement ponctuel majeur
Petites marches réversibles
administration de l'État
Fuite de glaçage, distorsion
Backend chiffré à distance + verrouillage
Erreurs courantes
- Postuler sans lire le plan. Le plan préfigure la suppression et la reconstruction ; S'il est ignoré, la perte de données est inévitable.
- Ne pas remarquer le défaut lâche. Les instances d'IA produisent fréquemment 0.0.0.0/0 ; S’il passe en production, cela signifie une source ouverte sur l’ensemble d’Internet.
- État de fuite. L'exportation du fichier d'état vers l'IA ou le référentiel ouvert expose des secrets en texte brut.
- Intégration de secrets dans le code. L'écriture du mot de passe dans le code IaC est une fuite persistante dans l'historique des versions du code.
- Confondre une reconstruction avec une mise à jour. Ignorer la ligne de remplacement des forces entraînera une perte de données dans les bases de données.
Astuce : Même lorsque vous confiez le résultat du plan à une IA pour qu'elle l'examine, basez la décision finale sur vos propres connaissances, et non sur le texte du plan. L'IA résume le plan et signale les lignes à risque ; mais la réponse à la question « cette suppression est-elle acceptable » dépend de votre contexte commercial.
En résumé
IaC apporte répétabilité et documentation en gérant l'infrastructure avec du code versionnable plutôt que des clics manuels. L'IA est un partenaire puissant pour écrire ce code, le décrire et le vérifier pour des raisons de sécurité. Mais la puissance de l’IaC réside dans son danger : une seule ligne peut anéantir toute l’infrastructure. Pensez déclaratif, commencez par l'autorisation la plus étroite, corrigez les valeurs par défaut, gardez les secrets hors du code et de l'état. Le garde-fou le plus vital est l’étape de planification/vérification : ne jamais exécuter sans lire les lignes de suppression et de reconstruction. Gardez l'État crypté, verrouillé et distant. Le code appartient à l'IA, la décision vous appartient.
Tâche de candidature
Choisissez une petite infrastructure cible (par exemple, une seule machine virtuelle et une règle de sécurité). Avec le modèle "Génération de ressources IaC" ci-dessus, demandez à l'IA un code avec des valeurs par défaut sûres. Vérifiez à nouveau le code avec le modèle « Examen de la sécurité du code IaC » et essayez de trouver au moins un paramètre lâche. Si possible, exécutez plan/--check sur un compte test et examinez le résultat avec le modèle « Vérification de sortie du plan » ; Vérifiez s'il y a une ligne de suppression ou de recréation. Notez vos conclusions et comment vous sécuriserez l’État en 6 points.
liste de contrôle
- [ ] Ai-je spécifié le cloud, l'outil et la version à l'IA et demandé le code avec les autorisations les plus étroites ?
- [ ] Ai-je vérifié les valeurs par défaut du code (0.0.0.0/0, cryptage fermé) ?
- [ ] Ai-je extrait les secrets de la variable au lieu de les intégrer dans le code ?
- [ ] Ai-je lu le résultat du plan/vérification et marqué les lignes de suppression avant de postuler ?
- [ ] Ai-je évalué l'impact des pertes de données liées au « remplacement des forces »/à la reconstruction des lignes ?
- N'ai-je pas gardé le fichier d'état [ ] crypté, verrouillé dans le backend distant et ne l'ai-je pas divulgué ?