Forvaltning av infrastruktur som kode (IaC): Terraform, Ansible og Plan Control

Gevinster:

• Evne til å produsere IaC (Terraform, Ansible) kode med kunstig intelligens med de smaleste tillatelsene og sikre standardinnstillingene og forstå den deklarative tilnærmingen
• Evne til å forhindre tap av data ved å lese og fange opp slette og tvinge erstatningslinjer før du bruker plan/sjekk utdata
• Evne til å forhindre hemmelig lekkasje ved å holde tilstandsfilen kryptert, låst i den eksterne backend og bryte endringer i små, reversible trinn

Forvaltning av infrastruktur som kode (IaC): Terraform, Ansible og Plan Control med AI

Tidligere ble det å sette opp en server med manuelle klikk, kommandoer og personlige notater; Resultatet var irreproduserbare "snøfnugg"-servere som ingen visste nøyaktig hvordan de skulle sette opp. Infrastructure as Code (IaC) er tilnærmingen som avslutter dette kaoset: servere, nettverk, sikkerhetsregler defineres ikke for hånd, men av versjonsbare tekstfiler (kode). Når du kjører denne koden, er infrastrukturen satt opp akkurat slik du skrev den – den samme, dokumenterte og repeterbar hver gang. De vanligste verktøyene er Terraform og CloudFormation for skyinfrastruktur og Ansible for serverkonfigurasjon. Her er AI veldig dyktig til å skrive, forklare og gjennomgå denne IaC-koden. Men kraften til IaC er også dens fare: én feil linje kan utslette en hel infrastruktur; så AI skriver kode, du leser "planen", godkjenner den og utfører den.

I denne enheten vil vi diskutere den deklarative tilnærmingen, plan/anvend distinksjonen, statssikkerhet og idempotens; Du vil lære IaC-generering med AI og den mest kritiske ferdigheten, "plankontroll".

Tenker deklarativt: "hva hvis", ikke "hvordan gjøre"

De fleste IaC-verktøy er deklarative: du beskriver den endelige tilstanden til systemet ("la oss si 3 webservere, 1 load balancer"), verktøyet beregner selv hvordan man kommer til den tilstanden. Dette er forskjellig fra å skrive et manus ("gjør dette, så gjør det" trinn for trinn). Den store fordelen med den deklarative tilnærmingen er idempotens: selv om du kjører koden ti ganger, er resultatet det samme, fordi verktøyet sjekker om den ønskede tilstanden allerede eksisterer, og hvis den gjør det, berører den den ikke. Husk denne forskjellen når du skriver IaC til AI: du får det til å si "la denne infrastrukturen stå", ikke "kjør disse kommandoene".

Planlegg/søk: mest vitale sikkerhetsrekkverk

Den livreddende funksjonen til IaC er plantrinnet. I Terraform, terraform plan, i Ansible, produserer --check-modus en forhåndsvisning av "hva vil endres hvis jeg bruker det" før du kjører koden: "2 ressurser vil bli lagt til, 1 vil endres, 0 vil bli slettet". Dette er den eneste måten å sammenligne intensjonen din med virkeligheten før implementering. Kritisk regel: søk aldri uten å ha lest planen. Se spesielt etter "ødelegge"-linjene; Hvis du ser "12 vil bli slettet" i stedet for "1 vil bli endret" på grunn av en skrivefeil, har planen reddet deg fra katastrofe. Etter å ha skrevet ut koden til AI, la den si "undersøk planens utdata linje for linje med meg, merk hver linje som inneholder sletting/rekreasjon."

Forsiktig: Noen endringer i Terraform "ødelegger og gjenskaper" en ressurs i stedet for å "oppdatere på plass". Dette betyr tap av data for en database. Å ignorere -/+ eller "tvinger erstatning" i planutdataene er en av de dyreste feilene.

Statsmappe: oversikt over hemmeligheter og sannhet

Verktøy som Terraform beholder den nåværende tilstanden til infrastrukturen de administrerer i en tilstandsfil. Denne filen er kritisk av to grunner. For det første kan det inneholde hemmeligheter (databasepassord, nøkler kan falle i tilstand i klartekst); Lim derfor aldri inn staten i et offentlig depot eller AI, hold den i en kryptert og tilgangsbegrenset ekstern backend. For det andre, hvis staten er ødelagt eller tapt, mister kjøretøyet koblingen mellom den virkelige infrastrukturen og den forestilte infrastrukturen; Derfor er en sikkerhetskopi av staten og en låsemekanisme (lås som hindrer to personer fra å bryte den samtidig) avgjørende.

Trinn for trinn: Sikre IaC med AI

1. Statens intensjon og leverandør. "2 servere på AWS, med Terraform, i denne regionen, denne størrelsen og en sikkerhetsgruppe." Hvis skyen, verktøyet og versjonen er klare, produserer AI riktig syntaks.
2. Be om sikkerhetsstandarder. "Åpne sikkerhetsgruppe, aktiver kryptering, trekk ut hemmeligheter til variable, gi offentlig tilgang." AI kan generere løse prøver som standard.
3. Les og forstå koden. Forstå hver ressurs, hver tillatelse, linje for linje. Ikke bruk en tillatelse du ikke forstår.
4. Få en plan og revider den. Kjør plan/--sjekk, undersøk utdataene med AI, merk slette- og gjenoppbygg linjene.
5. Påfør liten og vendbar. Gjennomfør en stor endring i små biter, ikke alle på en gang. Kjenn veien tilbake ved hvert trinn.
6. Beskytt staten. Bruk ekstern, kryptert backend og lås; Aldri lekkasjetilstand.

tre minisaker

Tilfelle 1 - Planen gjenopprettet en database. En ingeniør ønsket å øke størrelsen på en database med Terraform-koden han produserte med AI. Mens han forventet at "1 skulle endres" i terraform-planens utdata, så han "1 å ødelegge, 1 å legge til" - parameteren han valgte utløste en gjenoppbygging, ikke en oppdatering på stedet, noe som betyr at alle data ville bli slettet. Plankontroll stoppet irreversibelt tap av data før det ble implementert.

Tilfelle 2 — Retur fra løs standard. Et team ba AI om en brannmurkode. For å kjøre eksempelet genererte AI en enkel regel på 0.0.0.0/0, som betyr "offentlig på internett". Ingeniøren la merke til dette mens han leste koden og begrenset tilgangen til kun bedriftens IP-område. Hvis den ble implementert uten å bli revidert, ville databasen være åpen for hele internett.

Sak 3 — Statslekkasje forhindret. Et juniormedlem var i ferd med å lime inn terraform.tfstate-filen intakt i et offentlig verktøy for å løse et Terraform-problem. Senioringeniør stoppet: staten inneholdt et databasepassord i klartekst. I stedet ble et dekryptert sammendrag som beskriver problemet delt, og tilstanden ble flyttet til den eksterne krypterte backend.

Fire kopierbare maler

1) Generering av IaC-ressurser (sikker standard):

Din rolle: senior ingeniør for skyinfrastruktur. [Sky, f.eks. AWS] for[verktøy, f.eks. Terraform] generere kode. Formål: [formål].Sikkerhetsregler: offentlig (0.0.0.0/0) tilgang ÅPEN;start med smaleste tillatelse; slå på kryptering; trekke ut hemmeligheter i variabler, ikke bygg dem inn i kode; Sjekk innstillinger som kan føre til sletting/rekreasjon. Forklar hver kilde med en kort kommentar.

2) Planlegg utdatarevisjon:

Nedenfor er en [Terraform plan / Ansible check] utgang. Fortell meg: (1) hvor mange ressurser som vil bli lagt til/endret/slettet, (2) marker også linjene "ødelegg" eller "tvinger erstatning" som utgjør en risiko for tap av data, (3) liste opp eventuelle endringer som virker uventede eller farlige. Utgang: [plan]

3) IaC-kode sikkerhetsgjennomgang:

Undersøk følgende IaC-kode for sikkerhet: (1) er det for bred tilgang/tillatelser, (2) er kryptering slått av, (3) er det hemmeligheter innebygd i koden, (4) er det offentlig tilgjengelige ressurser? Foreslå korrigering for hvert funn. Kode: [maskert kode]

4) Del endringen i sikre deler:

Jeg ønsker ikke å implementere denne store infrastrukturendringen [forklaring] på en gang. Bryt det ned i små, uavhengige trinn som er enkle å komme tilbake til. For hvert trinn: hvilke endringer, hva bør jeg være oppmerksom på i planen, hvordan kan jeg angre det hvis det er problemer?

Svak forespørsel / Sterk forespørsel

Svak melding:

Skriv Terraform-kode som lager en server på AWS.

Region, størrelse, sikkerhet, nettverk, kryptering er uklart. AI produserer de løseste, mest eksplisitte standardene for å fungere - hvis den settes i produksjon, ville det være en sårbarhet.

Kraftig ledetekst:

Din rolle: senior ingeniør for skyinfrastruktur. Definer en webserver med Terraform på AWS eu-central-1: t3.small, bare fra bedriftens IP-område (jeg vil gi den med en variabel), port 443 er åpen, disken er kryptert, ingen offentlig tilgang, etiketter er obligatoriske. Hemmeligheter avsløres for variabelen. Etter koden: Før du implementerer den, fortell meg de 3 linjetypene jeg bør ta hensyn til i planen og forklar returveien.

Scene

Risiko

sikkerhetsrekkverk

skrive kode

Løs standard (offentlig)

Smaleste tillatelse + lesing

planlegge/sjekke

Sletter uten å være klar over det

Planlegg inspeksjon, ødelegge merking

Søk

Stor engangsendring

Små, vendbare trinn

statsadministrasjonen

Glasurlekkasje, forvrengning

Ekstern kryptert backend + lås

Vanlige feil

• Søker uten å lese planen. Planen varsler sletting og gjenoppbygging; Hvis det hoppes over, er tap av data uunngåelig.
• Merker ikke den løse standarden. AI-forekomster produserer ofte 0.0.0.0/0; Flyttes det til produksjon betyr det åpen kildekode til hele internett.
• Lekkende tilstand. Eksportering av tilstandsfilen til AI eller åpent depot avslører klarteksthemmeligheter.
• Innebygging av hemmeligheter i kode. Å skrive passordet inn i IaC-koden er en vedvarende lekkasje i kodeversjonshistorikken.
• Tar feil av en ombygging for en oppdatering. Ignorering av krafterstatningslinjen vil føre til tap av data i databaser.

Tips: Selv når du gir planen utdata til en AI for å vurdere, baser den endelige avgjørelsen på din egen kunnskap, ikke planteksten. AI oppsummerer planen og flagger risikable linjer; men svaret på spørsmålet "er denne slettingen akseptabel" avhenger av din forretningskontekst.

Oppsummert

IaC gir repeterbarhet og dokumentasjon ved å administrere infrastruktur med versjonskode i stedet for manuelle klikk. AI er en sterk partner når det gjelder å skrive denne koden, beskrive den og vurdere den for sikkerhets skyld. Men kraften til IaC er faren: én linje kan utslette hele infrastrukturen. Tenk deklarativt, start med den smaleste tillatelsen, fiks løse standarder, hold hemmeligheter utenfor kode og tilstand. Det viktigste rekkverket er plan-/sjekk-trinnet: utfør aldri uten å lese slette- og gjenoppbyggingslinjene. Hold staten kryptert, låst og ekstern. Koden er AI, avgjørelsen er din.

Søknadsoppgave

Velg et lite infrastrukturmål (for eksempel en enkelt virtuell maskin og en sikkerhetsregel). Med "IaC-ressursgenerering"-malen ovenfor, spør AI om en kode med sikre standardinnstillinger. Dobbeltsjekk koden med malen "IaC code security review" og prøv å finne minst én løs innstilling. Hvis mulig, kjør plan/--sjekk på en testkonto og gå gjennom utdataene med malen "Plan output check"; Se om det er en slette eller gjenopprett linje. Skriv ned funnene dine og hvordan du vil sikre staten i 6 punkter.

sjekkliste

• [ ] Spesifiserte jeg sky, verktøy og versjon til AI og ba om kode med de smaleste tillatelsene?
• [ ] Har jeg sjekket koden for løse standardinnstillinger (0.0.0.0/0, lukket kryptering)?
• [ ] Har jeg trukket ut hemmelighetene til variabelen i stedet for å legge dem inn i koden?
• [ ] Leste jeg planen/sjekket utdata og markerte slettelinjene før jeg søkte?
• [ ] Har jeg evaluert effekten av datatap av "tvinger erstatning" / gjenoppbyggingslinjer?
• Holdt jeg ikke [ ] State-filen kryptert, låst i den eksterne backend og lekket den ut?