Vinster:
- Förmåga att förstå IaC-konceptet och Terraforms arbetscykel (initiera, planera, tillämpa, tillstånd, modul) och ha artificiell intelligens producera säkra HCL-utkast
- Möjlighet att kontrollera varje förändring med en plan innan du ansöker och fånga oväntade förstöra/byta ut linjer
- Förmåga att tillämpa principerna för att hålla hemligheter utanför koden, hålla tillstånd säkert och minimera IAM-behörigheter
Förr var det att sätta upp en server en fråga om att klicka genom en molnpanel: skapa en virtuell maskin, konfigurera nätverket, lägg till säkerhetsregeln. Denna metod var långsam, felbenägen och kan inte upprepas - det var nästan omöjligt att ställa in samma miljö en andra gång. Idag hanteras infrastruktur som kod. IaC (Infrastructure as Code) är ett tillvägagångssätt för att beskriva molnresurser som servrar, nätverk och databaser i textfiler snarare än manuellt. Dessa filer sitter i versionskontroll (Git); Du kan se vem som ändrade vad, när och vad; Du kan ställa in samma infrastruktur många gånger, på exakt samma sätt, med ett kommando.
Det vanligaste IaC-verktyget är Terraform. Terraform tar definitionerna du skriver på ett läsbart språk som kallas HCL (HashiCorp Configuration Language — Terraforms konfigurationsspråk), översätter dem till molnleverantörens (AWS, Azure, GCP) API och skapar resurserna. AI:n känner till HCL mycket väl och producerar komplexa block snabbt. Men i IaC är kostnaden för ett misstag hög: en felaktig definition kan utplåna en hel produktionsdatabas. Det är därför den gyllene regeln i Terraform är att se varje förändring med en "plan" innan den implementeras.
Terraforms körtid
Terraform arbetar med tre grundläggande kommandon — att veta att dessa är en förutsättning för att styra AI-utdata:
- `terraform init`: Startar projektet, laddar ner nödvändiga leverantörsplugin.
- `terraform plan`: Jämför den aktuella situationen med den önskade situationen och visar vad som ska läggas till, vad som ska ändras, vad som ska raderas. Implementerar ingenting. Det är det mest kritiska säkerhetssteget.
- `terraform applicera`: Tillämpar faktiskt planen, skapar/ändrar resurser.
Dessutom är två koncept avgörande. Tillstånd (tillståndsfil): Detta är filen där Terraform behåller det aktuella tillståndet för de resurser som den hanterar; Det förvaras vanligtvis i ett avlägset och låst lager så att två personer inte kan ändra eller förstöra det samtidigt. Modul: Återanvändbart konfigurationspaket; Du kan till exempel använda modulen "set upp ett nätverk" i många projekt.
Tips: Det farligaste tecknet i en Terraform-utgång är förstöra eller -/+ (ersätt) linjer i planutgången. Dessa innebär att resursen kommer att raderas. Om du ser en oväntad förstörelse i en plan, ansök aldrig, först förstå varför den dök upp.
Steg för steg: Skriva IaC med AI
- Förtydliga önskad infrastruktur. Var konkret som "en VPC, två subnät, en säkerhetsgrupp och en t3.micro EC2 på eu-central-1".
- Ange leverantör och version. Vilket moln, vilken Terraform och leverantörsversion? Om du inte anger en version kan AI returnera föråldrad/inkompatibel syntax.
- Få HCL-utkastet framtaget. Begär även variabler och utdata.
- Ta ut hemligheten. Värden som lösenord och nycklar ska gå till variabeln och det hemliga valvet, inte till koden.
- Kör `init` + `plan`. Läs planens utdata rad för rad; Kontrollera om det finns oväntade raderingar.
- Börja smått, implementera gradvis. Använd det i ett isolerat testkonto/miljö först.
Säkerhet: IaC-specifika risker
IaC är lika riskabelt som kraftfullt. Tre kritiska punkter:
- Det finns en hemlighet i statens akt. Terraform state behåller ibland känsliga värden, såsom databaslösenord, i klartext. Placera aldrig staten i ett offentligt förvar; Använd en krypterad fjärrbackend med begränsad åtkomst.
- Bädda inte in hemligheter i HCL. Rader som password="prod123" skrivs permanent till Git-historiken. Använd istället en variabel och ange värdet vid körning från miljövariabeln (TF_VAR_...) eller hemligt valv.
- Mycket bred IAM-behörighet. AI producerar ibland block som Action: "*" (tillåt allt) för att "få det att fungera". Detta är en sårbarhet; begränsa tillståndet till det minimum som krävs.
Observera: När en hemlighet väl kommer in i Git-historiken förblir den i det förflutna och kan äventyras, även om du tar bort filen. Om du begår av misstag, avbryt omedelbart och rotera hemligheten; Det räcker inte att bara ta bort.
Riskabel plan tecken tabell
Planutskrift
Mening
vad man ska göra
+skapa
Ny resurs kommer att läggas till
Allmänt säker, recension dock
~ uppdatering på plats
Källan kommer att ändras på plats
Verifiera påverkan (kommer det att bli ett avbrott?)
-/+ ersätt
Kommer att raderas och återskapas
VARNING: dataförlust kan inträffa
- förstöra
Resursen kommer att förstöras
STOPP: ansök aldrig om du inte förväntar dig det
tre minifodral
Fall 1 — 2 dagars arbete på 3 timmar. Ett team skulle skriva Terraform för att sätta upp en ny testmiljö (VPC, subnät, RDS-databas, ECS-kluster) men de hade precis flyttat till HCL. De beskrev arkitekturen och versionerna av AI och tog fram en modulär ritning. De verifierade varje modul med planen och hade den igång på 3 timmar; Det skulle ta dem två dagar av manuellt försök och fel.
Fall 2 — planen fick en radering. En ingenjör körde en plan utan att använda en AI-genererad uppdateringskod. Utdatat innehöll -/+ ersätt för produktionsdatabasen - AI:n försökte ersätta ett icke-ersättbart fält, vilket innebar att ta bort och återskapa databasen. Ingenjören slutade tillämpa och ändrade ändringen till den säkra metoden. Vanan att planera förhindrade en katastrof.
Fall 3 — begravd hemlig läcka. En junior, YZ utfärdade db_password = "S3cret!" Han begick linjen som den är och sköt den. Fångad i kodgranskning; Lösenordet avbröts och ändrades omedelbart, värdet flyttades till en variabel och matades från det hemliga valvet. Lektion: Det finns aldrig hemligheter i klartext i HCL.
Fyra kopierbara mallar
1) Generera infrastrukturutkast:
Skriv följande infrastruktur på [CLOUD: AWS] med Terraform (version ~> 1.7): [SOURCE LIST]. Region [X]. Regler:- Gör alla känsliga värden variabla, bädda inte in dem i HCL.- Fix leverantörsversion (required_providers).- Minimera IAM-behörigheter, använd inte "*".- Returnera [X, Y] som utdata. Ge kod modulärt och med förklaringar.
2) Tolka planens utdata:
Analysera "terraform plan"-utgången nedan. Lista mig:(1) vilka resurser som lades till/ändrades/RADerades,(2) rader med risk för dataförlust eller avbrott,(3) 3 frågor jag bör ställa innan jag ansöker.Planera: [OUTPUT]
3) Undersök befintlig HCL för säkerhet:
Kontrollera följande Terraform-kod för säkerhet: inbäddad hemlighet, alltför bred IAM-behörighet, regel för öppet nätverk (0.0.0.0/0), okrypterad lagring? Skriv varje fynd i ordning efter betydelse och korrigering. Kod: [HCL]
4) Konvertera den repetitiva koden till modulen:
Konvertera följande repetitiva Terraform-kod till en återanvändbar modul: vilka värden ska vara variabler, vad ska modulgränssnittet vara? Visa också exempel på användning. Kod: [HCL]
Svag prompt / Stark prompt
Svag: "Skapa en databas med Terraform."
Resultat: oklart vilket moln, vilken motor, vilken version, krypterad eller inte; Med äldre syntax kan AI tillhandahålla ett allmänt tillgängligt exempel som bäddar in lösenordet i koden.
Stark: "Skapa en RDS PostgreSQL 15-instans på AWS med Terraform ~> 1.7. Gör lösenordsvariabeln, bädda inte in den i koden. Lagring är krypterad, tillgänglig endast från privat undernät, inte offentligt. Fixa leverantörsversion. Returnera slutpunkt som utdata."
Skillnad: den andra prompten ger motorn, versionen, kryptering, nätverksbegränsning och hemlig regel - utdata är säker och nära prod.
Vanliga misstag
- Att "ansöka" utan att göra en "plan". Det dyraste misstaget i IaC; planera alltid först.
- Inbädda hemlighet i HCL. Skapar permanent läckage till Git-historiken.
- Lagring staten osäker. En okrypterad, olåst offentlig stat är en katastrof.
- Fixar inte versionen. Att använda provider utan att ange en version kommer att leda till plötsliga fel i framtiden.
- *`Åtgärd: Bred behörighet som """.** Bryter mot principen om minsta privilegium.
- Ignorera oväntad "förstörelse". Tillämpa raderraderna i planen utan att ifrågasätta.
Sammanfattningsvis
IaC förvandlar infrastruktur till repeterbar, versionsbar och revisionsbar kod; Det vanligaste verktyget är Terraform. AI producerar snabbt HCL-stubbar, men du måste tillhandahålla versionen, molnspecifika detaljer och säkerhetsregler. Den ofelbara regeln i Terraform: att se varje förändring med en plan, att fråga om oväntade raderingar, att hålla hemligheter borta från koden och att hålla staten säkert. Förstöra och ersätta raderna i en planutgång är de platser som bör läsas noggrant.
Applikationsuppgift
Låt AI generera en liten infrastruktur (t.ex. en lagringshink och en åtkomstpolicy) med hjälp av mallen "Generera infrastrukturskiss" ovan. Sedan: (1) låt "vetting"-mallen kontrollera för hemliga eller * behörigheter inbäddade i koden; (2) om möjligt, kör init + plan i ett testkonto och läs planens utdata med mallen "plantolkning"; (3) notera eventuella oväntade raderingar/ändringar.
checklista
- [ ] Jag lade till moln, Terraform/leverantörsversion och kryptering/nätverksbegränsningar i min prompt.
- [ ] Det finns ingen hemlighet i klartext i koden; precisionsvärden variabla.
- [ ] Jag minskade IAM/behörigheter till minimala behörigheter, * Jag använde det inte.
- [ ] Jag körde planen innan applicera och läste utgången rad för rad.
- [ ] Jag har verifierat att det inte finns någon oväntad förstörelse/ersättning i planen.
- [ ] Jag är säker på att staten hålls i en krypterad, låst och begränsad backend.