Gevinster:
- Evne til å forstå IaC-konseptet og Terraforms arbeidssyklus (initiere, planlegge, anvende, angi, modul) og ha kunstig intelligens til å produsere sikre HCL-utkast
- Evne til å sjekke hver endring med en plan før påføring og fange opp uventede ødelegge/erstatte linjer
- Evne til å anvende prinsippene om å holde hemmeligheter utenfor koden, holde staten sikkert og minimere IAM-tillatelser
Tidligere var det å sette opp en server et spørsmål om å klikke gjennom et skypanel: lag en virtuell maskin, sett opp nettverket, legg til sikkerhetsregelen. Denne metoden var treg, utsatt for feil og kunne ikke gjentas - det var nesten umulig å sette opp det samme miljøet en gang til. I dag administreres infrastruktur som kode. IaC (Infrastructure as Code) er en tilnærming for å beskrive skyressurser som servere, nettverk og databaser i tekstfiler i stedet for manuelt. Disse filene sitter i versjonskontroll (Git); Du kan se hvem som endret hva, når og hva; Du kan sette opp den samme infrastrukturen mange ganger, på nøyaktig samme måte, med én kommando.
Det vanligste IaC-verktøyet er Terraform. Terraform tar definisjonene du skriver på et lesbart språk kalt HCL (HashiCorp Configuration Language — Terraforms konfigurasjonsspråk), oversetter dem til skyleverandørens (AWS, Azure, GCP) API og lager ressursene. AI kjenner HCL veldig godt og produserer komplekse blokker raskt. Men i IaC er kostnaden for en feil høy: én feil definisjon kan utslette en hel produksjonsdatabase. Det er derfor den gylne regel i Terraform er å se hver endring med en 'plan' før du implementerer den.
Terraforms kjøretid
Terraform fungerer med tre grunnleggende kommandoer - å vite at disse er en forutsetning for å kontrollere AI-utgang:
- `terraform init`: Starter prosjektet, laster ned nødvendige leverandørplugins.
- `terraform plan`: Sammenligner dagens situasjon med ønsket situasjon og viser hva som skal legges til, hva som skal endres, hva som skal slettes. Implementerer ingenting. Det er det mest kritiske sikkerhetstrinnet.
- `terraform gjelder`: Bruker faktisk planen, oppretter/modifiserer ressurser.
I tillegg er to konsepter avgjørende. State (tilstandsfil): Dette er filen der Terraform beholder gjeldende tilstand for ressursene den administrerer; Det er vanligvis lagret i et eksternt og låst lager slik at to personer ikke kan endre eller ødelegge det samtidig. Modul: Gjenbrukbar konfigurasjonspakke; Du kan for eksempel bruke modulen "sett opp et nettverk" i mange prosjekter.
Tips: Det farligste tegnet i en Terraform-utgang er ødelegge eller -/+ (erstatt) linjer i planutgangen. Disse betyr at ressursen vil bli slettet. Hvis du ser en uventet ødeleggelse i en plan, må du aldri søke, først forstå hvorfor den dukket opp.
Trinn for trinn: Skrive IaC med AI
- Avklar ønsket infrastruktur. Vær konkret som "en VPC, to undernett, en sikkerhetsgruppe og en t3.micro EC2 på eu-central-1".
- Angi leverandør og versjon. Hvilken sky, hvilken Terraform og leverandørversjon? Hvis du ikke spesifiserer en versjon, kan AI returnere utdatert/inkompatibel syntaks.
- Få HCL-utkastet produsert. Be om også variabler og utdata.
- Ta Secret ut. Verdier som passord og nøkler skal gå til det variable og hemmelige hvelvet, ikke til koden.
- Kjør `init` + `plan`. Les planens utdata linje for linje; Se etter uventede slettinger.
- Start i det små, implementer gradvis. Bruk den i en isolert testkonto/miljø først.
Sikkerhet: IaC-spesifikke risikoer
IaC er like risikabelt som det er kraftig. Tre kritiske punkter:
- Det er en hemmelighet i statens mappe. Terraform-tilstand beholder noen ganger sensitive verdier, for eksempel databasepassord, i klartekst. Legg aldri staten i et offentlig depot; Bruk en kryptert ekstern backend med begrenset tilgang.
- Ikke bygg inn hemmeligheter i HCL. Linjer som password="prod123" skrives permanent til Git-historikken. Bruk i stedet en variabel og oppgi verdien ved kjøring fra miljøvariabelen (TF_VAR_...) eller hemmelig hvelv.
- Veldig bred IAM-tillatelse. AI produserer noen ganger blokker som Action: "*" (tillat alt) for å "få det til å fungere". Dette er en sårbarhet; begrense tillatelsen til det minimum som kreves.
Oppmerksomhet: Når en hemmelighet kommer inn i Git-historien, forblir den i fortiden og kan bli kompromittert, selv om du sletter filen. Hvis du forplikter deg ved en feiltakelse, kanseller umiddelbart og roter hemmeligheten; Bare sletting er ikke nok.
Risikabelt planskilttabell
Planutskrift
Mening
hva du skal gjøre
+opprette
Ny ressurs vil bli lagt til
Generelt trygt, men vurdering
~ oppdatering på plass
Kilden vil endres på stedet
Bekreft virkningen (vil det være et strømbrudd?)
-/+ erstatte
Vil bli slettet og gjenskapt
FORSIKTIG: Datatap kan forekomme
- ødelegge
Ressursen vil bli ødelagt
STOPP: aldri søk hvis du ikke forventer det
tre minisaker
Sak 1 — 2 dagers arbeid på 3 timer. Ett team skulle skrive Terraform for å sette opp et nytt testmiljø (VPC, subnett, RDS-database, ECS-klynge), men de hadde nettopp flyttet til HCL. De beskrev arkitekturen og versjonene til AI og produserte en modulær plan. De verifiserte hver modul med planen og hadde den i gang på 3 timer; Det ville ta dem to dager med manuell prøving og feiling.
Tilfelle 2 - planen ble slettet. En ingeniør kjørte en plan uten å bruke en AI-generert oppdateringskode. Utdataene inneholdt -/+ erstatning for produksjonsdatabasen - AI forsøkte å erstatte et ikke-erstattbart felt, noe som innebar å slette og gjenskape databasen. Ingeniøren sluttet å bruke og endret endringen til sikker metode. Vanen med å planlegge forhindret en katastrofe.
Sak 3 — begravd hemmelig lekkasje. En junior, YZ utstedte db_password = "S3cret!" Han begått linjen som den er og presset den. Fanget i kodegjennomgang; Passordet ble umiddelbart kansellert og endret, verdien ble flyttet til en variabel og matet fra det hemmelige hvelvet. Leksjon: Det er aldri klartekst hemmeligheter i HCL.
Fire kopierbare maler
1) Generering av infrastrukturutkast:
Skriv følgende infrastruktur på [CLOUD: AWS] med Terraform (versjon ~> 1.7): [SOURCE LIST]. Region [X]. Regler:- Gjør alle sensitive verdier variable, ikke bygg dem inn i HCL.- Fix provider-versjon (required_providers).- Minimer IAM-tillatelser, ikke bruk "*".- Returner [X, Y] som utdata. Gi kode modulært og med forklaringer.
2) Tolking av planens utdata:
Analyser 'terraform plan'-utgangen nedenfor. Skriv meg opp:(1) hvilke ressurser som ble lagt til/endret/SLETTET,(2) rader med fare for tap av data eller avbrudd,(3) 3 spørsmål jeg bør stille før jeg søker.Plan: [OUTPUT]
3) Undersøk eksisterende HCL for sikkerhet:
Sjekk følgende Terraform-kode for sikkerhet: innebygd hemmelighet, altfor bred IAM-tillatelse, åpen nettverksregel (0.0.0.0/0), ukryptert lagring? Skriv hvert funn i rekkefølge etter viktighet og korrigering. Kode: [HCL]
4) Konverter den repeterende koden til modulen:
Konverter følgende repeterende Terraform-kode til en gjenbrukbar modul: hvilke verdier skal være variabler, hva skal modulgrensesnittet være? Vis også eksempelbruk. Kode: [HCL]
Svak forespørsel / Sterk forespørsel
Svak: "Opprett en database med Terraform."
Resultat: uklart hvilken sky, hvilken motor, hvilken versjon, kryptert eller ikke; Med eldre syntaks kan AI gi et offentlig tilgjengelig eksempel som bygger inn passordet i koden.
Sterk: "Opprett en RDS PostgreSQL 15-instans på AWS med Terraform ~> 1.7. Gjør passordvariabelen, ikke bygg den inn i koden. Lagring er kryptert, kun tilgjengelig fra privat subnett, ikke offentlig. Fiks leverandørversjon. Returner endepunkt som utdata."
Forskjell: den andre ledeteksten gir motor, versjon, kryptering, nettverksbegrensning og hemmelig regel - utgangen er sikker og nær prod.
Vanlige feil
- Å "søke" uten å lage en "plan". Den dyreste feilen i IaC; alltid planlegge først.
- Innebyggingshemmelighet i HCL. Skaper permanent lekkasje inn i Git-historien.
- Lagring av staten usikker. En ukryptert, ulåst, offentlig stat er en katastrofe.
- Retter ikke versjonen. Bruk av leverandør uten å spesifisere en versjon vil føre til plutselige feil i fremtiden.
- *`Handling: Bred tillatelse som ""`.** Bryter prinsippet om minste privilegium.
- Ignorerer uventet "ødelegge". Bruk av slettelinjene i planen uten å stille spørsmål.
Oppsummert
IaC gjør infrastruktur til repeterbar, versjonerbar og reviderbar kode; Det vanligste verktøyet er Terraform. AI produserer raskt HCL-stubber, men du må oppgi versjonen, skyspesifikke detaljer og sikkerhetsregler. Den ufeilbarlige regelen i Terraform: å se hver endring med en plan, å spørre etter uventede slettinger, å holde hemmeligheter borte fra koden og å holde staten trygt. Ødelegg og erstatt linjene i en planutgang er stedene som bør leses mest nøye.
Søknadsoppgave
Få AI til å generere en liten infrastruktur (f.eks. en lagringsbøtte og en tilgangspolicy) ved å bruke malen "Generer infrastrukturskisse" ovenfor. Deretter: (1) la "vetting"-malen se etter hemmelige eller *-tillatelser innebygd i koden; (2) hvis mulig, kjør init + plan i en testkonto og les planutdataene med malen "plantolkning"; (3) legg merke til eventuelle uventede slettinger/endringer.
sjekkliste
- [ ] Jeg la til sky, Terraform/leverandørversjon og kryptering/nettverksbegrensninger i forespørselen min.
- [ ] Det er ingen klarteksthemmelighet i koden; variable presisjonsverdier.
- [ ] Jeg begrenset IAM/tillatelser til minimale tillatelser, * Jeg brukte det ikke.
- [ ] Jeg kjørte plan før søknad og leste utdata linje for linje.
- [ ] Jeg bekreftet at det ikke er noen uventet ødeleggelse/erstatning i planen.
- [ ] Jeg er sikker på at staten holdes i en kryptert, låst og begrenset backend.