Vinster:
- Förmåga att producera IaC (Terraform, Ansible)-kod med artificiell intelligens med de smalaste behörigheterna och säkra standardinställningarna och förstå det deklarativa tillvägagångssättet
- Möjlighet att förhindra dataförlust genom att läsa och fånga radering och tvinga ersättningsrader innan du tillämpar planen/kontrollera utdata
- Möjlighet att förhindra hemligt läckage genom att hålla tillståndsfilen krypterad, låst, i fjärrbackend och bryta upp ändringar i små, reversibla steg
Hantering av infrastruktur som kod (IaC): Terraform, Ansible och Plan Control med AI
Tidigare gjordes inställningen av en server med manuella klick, kommandon och personliga anteckningar; Resultatet blev irreproducerbara "snöflinga"-servrar som ingen visste exakt hur de skulle ställa in. Infrastructure as Code (IaC) är tillvägagångssättet som avslutar detta kaos: servrar, nätverk, säkerhetsregler definieras inte för hand, utan av versionsbara textfiler (kod). När du kör den här koden ställs infrastrukturen upp precis som du skrev den – samma, dokumenterade och repeterbara varje gång. De vanligaste verktygen är Terraform och CloudFormation för molninfrastruktur och Ansible för serverkonfiguration. Här är AI:n väldigt skicklig på att skriva, förklara och granska denna IaC-kod. Men kraften i IaC är också dess fara: en fel linje kan utplåna en hel infrastruktur; så AI:n skriver kod, du läser "planen", godkänner den och kör den.
I denna enhet kommer vi att diskutera det deklarativa tillvägagångssättet, distinktionen planera/tillämpa, statens säkerhet och idempotens; Du kommer att lära dig IaC-generering med AI och den mest kritiska färdigheten, "plankontroll".
Tänker deklarativt: "tänk om", inte "hur man gör"
De flesta IaC-verktyg är deklarativa: du beskriver systemets slutliga tillstånd ("låt oss säga 3 webbservrar, 1 belastningsutjämnare"), verktyget beräknar själv hur man kommer till det tillståndet. Detta skiljer sig från att skriva ett manus ("gör det här, gör sedan det" steg för steg). Den stora fördelen med det deklarativa tillvägagångssättet är idempotens: även om du kör koden tio gånger blir resultatet detsamma, eftersom verktyget kontrollerar om det önskade tillståndet redan existerar, och om det gör det, rör det inte det. Kom ihåg denna skillnad när du skriver IaC till AI:n: du får det att säga "låt den här infrastrukturen stå", inte "kör dessa kommandon".
Planera/applicera: det viktigaste säkerhetsräcket
Den livräddande funktionen hos IaC är plansteget. I Terraform, terraform plan, i Ansible, ger --check-läget en förhandsvisning av "vad kommer att förändras om jag tillämpar det" innan koden körs: "2 resurser kommer att läggas till, 1 kommer att ändras, 0 kommer att tas bort". Detta är det enda sättet att jämföra din avsikt med verkligheten innan implementering. Kritisk regel: ansök aldrig utan att ha läst planen. Leta särskilt efter "förstöra"-linjerna; Om du ser "12 kommer att raderas" istället för "1 kommer att ändras" på grund av ett stavfel, har planen räddat dig från katastrof. Efter att ha skrivit ut koden till AI:n, låt det stå "undersök planens utdata rad för rad med mig, markera varje rad som innehåller radering/återskapande."
Varning: Vissa ändringar av Terraform "förstör och återskapar" en resurs snarare än "uppdaterar på plats". Detta innebär dataförlust för en databas. Att ignorera -/+ eller "tvingar ersättning" i planutgången är ett av de dyraste misstagen.
Statens fil: register över hemligheter och sanning
Verktyg som Terraform behåller det aktuella tillståndet för infrastrukturen de hanterar i en tillståndsfil. Den här filen är kritisk av två anledningar. För det första kan det innehålla hemligheter (databaslösenord, nycklar kan falla i status i klartext); Klistra därför aldrig in staten i ett offentligt arkiv eller AI, håll det i en krypterad och åtkomstbegränsad fjärrbackend. För det andra, om staten är korrumperad eller förlorad, förlorar fordonet länken mellan den verkliga infrastrukturen och den tänkta infrastrukturen; Därför är en säkerhetskopia av staten och en låsmekanism (lås som hindrar två personer från att bryta den samtidigt) väsentliga.
Steg för steg: Säkra IaC med AI
- Statens avsikt och tillhandahållare. "2 servrar på AWS, med Terraform, i denna region, denna storlek och en säkerhetsgrupp." Om molnet, verktyget och versionen är tydliga, producerar AI korrekt syntax.
- Begär säkerhetsstandarder. "Öppna säkerhetsgrupp, aktivera kryptering, extrahera hemligheter till variabel, ge allmän tillgång." AI kan generera lösa prover som standard.
- Läs och förstå koden. Förstå varje resurs, varje behörighet, rad för rad. Använd inte en behörighet du inte förstår.
- Skaffa en plan och granska den. Kör plan/--check, undersök utdata med AI, markera raderna för radering och bygg om.
- Applicera liten och vändbar. Genomför en stor förändring i små bitar, inte alla på en gång. Vet vägen tillbaka vid varje steg.
- Skydda staten. Använd fjärrkontroll, krypterad backend och lås; Aldrig läcka tillstånd.
tre minifodral
Fall 1 — Planen återställde en databas. En ingenjör ville utöka storleken på en databas med Terraform-koden han producerade med AI. Medan han förväntade sig att "1 skulle ändras" i terraform-planens utdata, såg han "1 att förstöra, 1 att lägga till" - parametern han valde utlöste en ombyggnad, inte en uppdatering på plats, vilket betyder att all data skulle raderas. Plankontroll stoppade oåterkallelig dataförlust innan den implementerades.
Fall 2 — Återgå från lös standard. Ett team bad AI om en brandväggskod. För att köra exemplet genererade AI en enkel regel på 0.0.0.0/0, vilket betyder "offentligt på internet". Ingenjören märkte detta när han läste koden och begränsade åtkomsten till endast företagets IP-intervall. Om den implementerades utan att bli granskad skulle databasen vara öppen för hela internet.
Fall 3 — Statsläcka förhindras. En juniormedlem var på väg att klistra in terraform.tfstate-filen intakt i ett offentligt verktyg för att lösa ett Terraform-problem. Senior ingenjör slutade: staten innehöll ett lösenord för en vanlig databas. Istället delades en dekrypterad sammanfattning som beskrev problemet och tillståndet flyttades till den fjärrkrypterade backend.
Fyra kopierbara mallar
1) Generering av IaC-resurser (säker standard):
Din roll: senior molninfrastrukturingenjör. [Moln, t.ex. AWS] för[verktyg, t.ex. Terraform] generera kod. Syfte: [syfte].Säkerhetsregler: offentlig (0.0.0.0/0) åtkomst ÖPPEN;börja med smalaste tillstånd; aktivera kryptering; extrahera hemligheter till variabler, bädda inte in dem i kod; Kontrollera inställningar som kan leda till radering/återskapande. Förklara varje källa med en kort kommentar.
2) Planera utdatarevision:
Nedan finns en [Terraform plan / Ansible check] utgång. Berätta för mig: (1) hur många resurser som kommer att läggas till/ändras/ta bort, (2) markera också raderna "förstör" eller "tvingar ersättning" som utgör en risk för dataförlust, (3) lista alla ändringar som verkar oväntade eller farliga. Utdata: [plan]
3) IaC-kodsäkerhetsgranskning:
Undersök följande IaC-kod för säkerhet: (1) finns det alltför bred åtkomst/behörigheter, (2) är kryptering avstängd, (3) finns det hemligheter inbäddade i koden, (4) finns det allmänt tillgängliga resurser? Föreslå korrigering för varje fynd. Kod: [maskerad kod]
4) Dela upp bytet i säkra delar:
Jag vill inte implementera denna stora infrastrukturförändring [förklaring] på en gång. Dela upp det i små, oberoende steg som är lätta att komma tillbaka till. För varje steg: vilka förändringar, vad ska jag vara uppmärksam på i planen, hur ångrar jag det om det finns problem?
Svag prompt / Stark prompt
Svag uppmaning:
Skriv Terraform-kod som skapar en server på AWS.
Region, storlek, säkerhet, nätverk, kryptering är oklart. AI producerar de lösaste, mest explicita standardinställningarna för att fungera - om det sätts i produktion skulle det vara en sårbarhet.
Kraftfull uppmaning:
Din roll: senior molninfrastrukturingenjör. Definiera en webbserver med Terraform på AWS eu-central-1: t3.small, endast från företagets IP-intervall (jag kommer att ge det med en variabel), port 443 är öppen, disken är krypterad, ingen offentlig åtkomst, etiketter är obligatoriska. Hemligheter avslöjas för variabeln. Efter koden: Innan du implementerar den, berätta för mig de 3 linjetyperna jag bör vara uppmärksam på i planen och förklara returvägen.
Scen
Risk
säkerhetsräcke
skriva kod
Lös standard (offentlig)
Snävaste behörighet + läs
planera/kolla
Raderar utan att inse det
Planera besiktning, förstör märkning
Ansök
Stor engångsförändring
Små, vändbara steg
statsförvaltningen
Glasyrläckage, distorsion
Fjärrkrypterad backend + lås
Vanliga misstag
- Ansöker utan att ha läst planen. Planen förebådar strykning och återuppbyggnad; Om den hoppas över är dataförlust oundviklig.
- Märker inte den lösa standarden. AI-instanser producerar ofta 0.0.0.0/0; Om den flyttas till produktion innebär det öppen källkod till hela internet.
- Läckande tillstånd. Att exportera tillståndsfilen till AI eller öppet arkiv avslöjar klartexthemligheter.
- Bädda in hemligheter i kod. Att skriva in lösenordet i IaC-koden är en ihållande läcka i kodversionshistoriken.
- Misstag en ombyggnad för en uppdatering. Att ignorera kraftersättningslinjen kommer att resultera i dataförlust i databaser.
Tips: Även när du ger planen utdata till en AI att granska, basera det slutliga beslutet på din egen kunskap, inte plantexten. AI sammanfattar planen och flaggar riskfyllda linjer; men svaret på frågan "är denna radering acceptabel" beror på ditt affärssammanhang.
Sammanfattningsvis
IaC ger repeterbarhet och dokumentation genom att hantera infrastruktur med versionsbar kod snarare än manuella klick. AI är en kraftfull partner när det gäller att skriva den här koden, beskriva den och granska den för säkerhets skull. Men kraften med IaC är dess fara: en linje kan utplåna hela infrastrukturen. Tänk deklarativt, börja med den smalaste behörigheten, fixa lösa standardinställningar, håll hemligheter borta från kod och tillstånd. Det viktigaste skyddsräcket är plan-/kontrollsteget: kör aldrig utan att läsa raderna för radering och ombyggnad. Håll staten krypterad, låst och fjärrstyrd. Koden är AI:s, beslutet är ditt.
Applikationsuppgift
Välj ett litet infrastrukturmål (till exempel en enda virtuell maskin och en säkerhetsregel). Med mallen "IaC-resursgenerering" ovan, fråga AI om en kod med säkra standardinställningar. Dubbelkolla koden med mallen "IaC-kodsäkerhetsgranskning" och försök hitta minst en lös inställning. Om möjligt, kör plan/--check på ett testkonto och granska utdata med mallen "Plan output check"; Se om det finns en radera eller återskapa rad. Skriv ner dina resultat och hur du ska säkra staten i 6 punkter.
checklista
- [ ] Angav jag moln, verktyg och version till AI och begärde kod med de smalaste behörigheterna?
- [ ] Har jag kontrollerat koden för lösa standardvärden (0.0.0.0/0, stängd kryptering)?
- [ ] Har jag extraherat hemligheterna till variabeln istället för att bädda in dem i koden?
- [ ] Läste jag planen/kontrollerade resultatet och markerade raderna innan jag ansökte?
- [ ] Har jag utvärderat inverkan på dataförlusten av "tvingar ersättning" / ombyggnadslinjer?
- Hade jag inte [ ] State-filen krypterad, låst i fjärrbackend och läckte ut den?