Unità 3 / 11

Gestire l'infrastruttura come codice: intelligenza artificiale con Terraform e IaC

Guadagni:

  • Capacità di comprendere il concetto IaC e il ciclo di lavoro di Terraform (init, pianificazione, applicazione, stato, modulo) e di fare in modo che l'intelligenza artificiale produca bozze HCL sicure
  • Possibilità di controllare ogni modifica con un piano prima di applicarla e di individuare linee di distruzione/sostituzione impreviste
  • Capacità di applicare i principi di mantenere i segreti fuori dal codice, mantenere lo stato sicuro e ridurre al minimo le autorizzazioni IAM

In passato, configurare un server era questione di fare clic su un pannello cloud: creare una macchina virtuale, configurare la rete, aggiungere la regola di sicurezza. Questo metodo era lento, soggetto a errori e irripetibile: era quasi impossibile configurare lo stesso ambiente una seconda volta. Oggi l’infrastruttura è gestita come codice. IaC (Infrastructure as Code) è un approccio per descrivere le risorse cloud come server, reti e database in file di testo anziché manualmente. Questi file si trovano nel controllo della versione (Git); Puoi vedere chi ha cambiato cosa, quando e cosa; Puoi configurare la stessa infrastruttura più volte, esattamente nello stesso modo, con un solo comando.

Lo strumento IaC più comune è Terraform. Terraform prende le definizioni che scrivi in ​​un linguaggio leggibile chiamato HCL (HashiCorp Configuration Language: il linguaggio di configurazione di Terraform), le traduce nell'API del provider cloud (AWS, Azure, GCP) e crea le risorse. L'IA conosce molto bene l'HCL e produce rapidamente blocchi complessi. Ma in IaC il costo di un errore è elevato: una definizione sbagliata può cancellare un intero database di produzione. Ecco perché la regola d'oro in Terraform è vedere ogni cambiamento con un "piano" prima di implementarlo.

Runtime di Terraform

Terraform funziona con tre comandi di base: sapere che questi sono un prerequisito per controllare l'output dell'IA:

  • `terraform init`: avvia il progetto, scarica i plugin del provider necessari.
  • `piano terraform`: confronta la situazione attuale con la situazione desiderata e mostra cosa aggiungere, cosa cambiare, cosa eliminare. Non implementa nulla. È il passaggio di sicurezza più critico.
  • `terraform apply`: applica effettivamente il Piano, creando/modificando le risorse.

Inoltre, due concetti sono vitali. State (file di stato): questo è il file in cui Terraform conserva lo stato corrente delle risorse che gestisce; Di solito viene conservato in un magazzino remoto e chiuso a chiave in modo che due persone non possano modificarlo o distruggerlo contemporaneamente. Modulo: pacchetto di configurazione riutilizzabile; Ad esempio, in molti progetti puoi utilizzare il modulo "Configura una rete".

Suggerimento: il segnale più pericoloso in un output Terraform sono le linee di distruzione o -/+ (sostituzione) nell'output del piano. Ciò significa che la risorsa verrà eliminata. Se vedi una distruzione inaspettata in un piano, non applicarla mai, prima capisci perché è apparsa.

Passo dopo passo: scrivere IaC con l'intelligenza artificiale

  1. Chiarire l'infrastruttura desiderata. Sii concreto come "un VPC, due sottoreti, un gruppo di sicurezza e un t3.micro EC2 su eu-central-1".
  2. Specificare provider e versione. Quale cloud, quale Terraform e quale versione del provider? Se non specifichi una versione, l'intelligenza artificiale potrebbe restituire una sintassi obsoleta/incompatibile.
  3. Far produrre la bozza dell'HCL. Richiedi anche variabili e output.
  4. Porta fuori il Segreto. Valori come password e chiavi dovrebbero andare alla variabile e al deposito segreto, non al codice.
  5. Esegui `init` + `plan`. Leggere riga per riga l'output del piano; Verifica la presenza di eliminazioni impreviste.
  6. Inizia in piccolo, implementa gradualmente. Applicalo prima in un account/ambiente di prova isolato.

Sicurezza: rischi specifici della IaC

La IaC è tanto rischiosa quanto potente. Tre punti critici:

  1. C'è un segreto nel dossier di stato. Lo stato Terraform a volte mantiene i valori sensibili, come le password del database, in testo non crittografato. Non inserire mai lo Stato in un archivio pubblico; Utilizza un backend remoto crittografato e ad accesso limitato.
  2. Non incorporare segreti nell'HCL. Righe come password="prod123" vengono scritte in modo permanente nella cronologia di Git. Utilizzare invece una variabile e fornire il valore in fase di esecuzione dalla variabile di ambiente (TF_VAR_...) o dal vault segreto.
  3. Autorizzazione IAM molto ampia. L'intelligenza artificiale a volte produce blocchi come Azione: "*" (consenti tutto) per "farlo funzionare". Questa è una vulnerabilità; restringere l'autorizzazione al minimo richiesto.
Attenzione: una volta che un segreto entra nella cronologia di Git, rimane nel passato e può essere compromesso, anche se elimini il file. Se commetti per errore, annulla e ruota immediatamente il segreto; La semplice eliminazione non è sufficiente.

Tabella dei segnali del piano rischioso

Stampa del piano

Significato

cosa fare

+creare

Verrà aggiunta una nuova risorsa

Generalmente sicuro, rivedilo però

~ aggiornamento sul posto

La fonte cambierà sul posto

Verificare l'impatto (ci sarà un'interruzione?)

-/+ sostituisci

Verrà eliminato e ricreato

ATTENZIONE: potrebbe verificarsi una perdita di dati

- distruggere

La risorsa verrà distrutta

STOP: non candidarti mai se non te lo aspetti

tre mini custodie

Caso 1 — 2 giorni di lavoro in 3 ore. Un team stava per scrivere Terraform per configurare un nuovo ambiente di test (VPC, sottoreti, database RDS, cluster ECS) ma si era appena spostato su HCL. Hanno descritto l'architettura e le versioni dell'IA e hanno prodotto un progetto modulare. Hanno verificato ogni modulo con il piano e lo hanno reso operativo in 3 ore; Ci sarebbero voluti due giorni di tentativi ed errori manuali.

Caso 2: il piano ha rilevato un'eliminazione. Un ingegnere ha eseguito un piano senza applicare un codice di aggiornamento generato dall'intelligenza artificiale. L'output conteneva -/+ replace per il database di produzione: l'IA ha tentato di sostituire un campo non sostituibile, il che significava eliminare e ricreare il database. L'ingegnere ha interrotto l'applicazione e ha apportato la modifica al metodo sicuro. L’abitudine di pianificare ha impedito un disastro.

Caso 3: fuga segreta sepolta. Un giovane, YZ, ha rilasciato db_password = "S3cret!" Ha impegnato la linea così com'è e l'ha spinta. Catturato nella revisione del codice; La password è stata immediatamente cancellata e modificata, il valore è stato spostato in una variabile e alimentato dal caveau segreto. Lezione: non ci sono mai segreti in chiaro in HCL.

Quattro modelli copiabili

1) Generazione del progetto dell'infrastruttura:

Scrivere la seguente infrastruttura su [CLOUD: AWS] con Terraform (versione ~> 1.7): [ELENCO FONTI]. Regione [X]. Regole:- Rendi variabili tutti i valori sensibili, non incorporarli nell'HCL.- Correggi la versione del provider (required_providers).- Riduci al minimo le autorizzazioni IAM, non utilizzare "*".- Restituisci [X, Y] come output. Fornire il codice in modo modulare e con spiegazioni.

2) Interpretare i risultati del piano:

Analizzare l'output del "piano terraform" di seguito. Elencami: (1) quali risorse sono state aggiunte/modificate/ELIMINATE, (2) righe a rischio di perdita o interruzione dei dati, (3) 3 domande che dovrei porre prima di presentare domanda. Pianifica: [OUTPUT]

3) Esaminare l'HCL esistente per motivi di sicurezza:

Controllare il seguente codice Terraform per motivi di sicurezza: segreto incorporato, autorizzazione IAM eccessivamente ampia, regola di rete aperta (0.0.0.0/0), archiviazione non crittografata? Scrivi ogni risultato in ordine di importanza e correzione. Codice: [HCL]

4) Convertire il codice ripetitivo nel modulo:

Converti il seguente codice Terraform ripetitivo in un modulo riutilizzabile: quali valori dovrebbero essere variabili, quale dovrebbe essere l'interfaccia del modulo? Mostra anche un esempio di utilizzo. Codice: [HCL]

Prompt debole / Prompt forte

Debole: "Crea un database con Terraform".

Risultato: non chiaro quale cloud, quale motore, quale versione, crittografato o meno; Con la sintassi legacy, l'intelligenza artificiale può fornire un esempio disponibile al pubblico che incorpora la password nel codice.

Forte: "Crea un'istanza RDS PostgreSQL 15 su AWS con Terraform ~> 1.7. Crea la variabile password, non incorporarla nel codice. Lo storage è crittografato, accessibile solo dalla sottorete privata, non pubblica. Correggi la versione del provider. Restituisci l'endpoint come output."

Differenza: il secondo prompt fornisce motore, versione, crittografia, vincolo di rete e regola segreta: l'output è sicuro e vicino alla produzione.

Errori comuni

  • “Applicare” senza fare un “piano”. L'errore più costoso in IaC; pianificare sempre prima.
  • Incorporamento del segreto nell'HCL. Crea perdite permanenti nella cronologia di Git.
  • Conservazione dello Stato insicuro. Uno stato pubblico non crittografato e sbloccato è un disastro.
  • Non correggere la versione. L'utilizzo del provider senza specificare una versione porterà a improvvisi errori in futuro.
  • *`Azione: autorizzazione ampia come ""`.** Viola il principio del privilegio minimo.
  • Ignorando la "distruzione" inaspettata. Applicare le righe di eliminazione nel Piano senza fare domande.

In sintesi

IaC trasforma l'infrastruttura in codice ripetibile, modificabile e verificabile; Lo strumento più comune è Terraform. L'intelligenza artificiale produce rapidamente stub HCL, ma è necessario fornire la versione, i dettagli specifici del cloud e le regole di sicurezza. La regola infallibile in Terraform: vedere ogni modifica con un piano, interrogare eliminazioni inaspettate, mantenere i segreti lontani dal codice e mantenere lo stato in sicurezza. Le righe di distruzione e sostituzione nell'output di un piano sono i punti che dovrebbero essere letti con maggiore attenzione.

Compito dell'applicazione

Chiedi all'IA di generare una piccola infrastruttura (ad esempio un bucket di archiviazione e una policy di accesso) utilizzando il modello "Genera schizzo dell'infrastruttura" sopra. Quindi: (1) fare in modo che il modello "vetting" controlli le autorizzazioni segrete o * incorporate nel codice; (2) se possibile, eseguire init + plan in un account di prova e leggere l'output del piano con il modello "interpretazione del piano"; (3) annotare eventuali cancellazioni/modifiche impreviste.

lista di controllo

  • [ ] Ho aggiunto vincoli relativi a cloud, Terraform/provider e crittografia/rete al mio prompt.
  • [ ] Nel codice non è presente alcun segreto in testo normale; valori di precisione variabili.
  • [ ] Ho ristretto il campo IAM/autorizzazioni alle autorizzazioni minime, * Non l'ho utilizzato.
  • [] Ho eseguito il piano prima dell'applicazione e ho letto l'output riga per riga.
  • [ ] Ho verificato che non vi siano distruzioni/sostituzioni impreviste nel Piano.
  • [] Sono sicuro che lo stato sia mantenuto in un backend crittografato, bloccato e limitato.