Terraform cu AI în 2026: generare, review de plan, policy as code

Terraform cu AI înseamnă că un asistent sau un agent de cod scrie HCL-ul, iar echipa de platformă răspunde pentru ce ajunge în cloud. Diferența față de codul de aplicație este că aici o greșeală nu pică un test, ci șterge o bază de date sau deschide un port către internet. Ghidul de mai jos fixează fluxul: ce poate genera modelul, cum citești planul înainte de apply, ce verifică pipeline-ul, ce nu intră în contextul agentului și cine are drept de apply.

Terraform cu AI: de ce IaC nu e „încă un fișier de cod”

Un agent care scrie o funcție greșită primește înapoi un test roșu. Un agent care scrie HCL greșit nu primește nimic până la apply. Trei lucruri fac diferența:

• Codul se execută asupra unor resurse reale, cu credențiale reale.
• Corectitudinea depinde de state, un fișier care nu stă în depozit și pe care modelul nu îl vede. Același HCL înseamnă „nicio schimbare” cu state-ul corect și „creează totul din nou” fără el.
• Semnalul apare târziu. terraform validate trece și pe o configurație care înlocuiește baza de date; consecința se vede abia în plan.

Un caz real le leagă pe toate trei. Pe 26 februarie 2026, Alexey Grigorev, de la DataTalks.Club, migra un site pe AWS cu un agent de cod căruia îi delegase terraform plan și terraform apply. State-ul rămăsese local, pe un calculator vechi; fără el, au fost create resurse duplicate. În timpul curățeniei, agentul a despachetat o arhivă adusă de pe vechiul calculator și a înlocuit state-ul curent cu unul mai vechi, care descria platforma de cursuri din producție. A urmat un terraform destroy, pe care autorul nu l-a oprit. Au dispărut baza de date RDS, VPC-ul, clusterul ECS și snapshot-urile automate; datele au fost recuperate după aproximativ 24 de ore, dintr-un snapshot găsit de suportul AWS. În analiza publicată pe 6 martie 2026, autorul își asumă cauza: „I treated plan, apply, and destroy as something that could be delegated. That removed the last safety layer.” Măsurile lui de după: state remote, protecție la ștergere, fiecare plan citit de un om, nicio comandă distructivă rulată de agent.

Ghidul despre AIOps prezintă IaC cu AI ca una dintre zonele în care AI devine concret pentru echipele de operațiuni. Aici intrăm în detaliu, pe Terraform și OpenTofu. Fluxul de mai jos este cel exersat în modulul de IaC al cursului AI pentru DevOps și SRE (AIOps).

Generare Terraform cu AI: ce scrie modelul și cum verifici

Modelele scriu HCL plauzibil, iar „plauzibil” acoperă și argumente care nu există în versiunea ta de provider. Regula: pentru fiecare tip de artefact generat există o verificare deterministă, iar propunerea nu trece mai departe fără ea.

Repere din documentația Terraform 1.16: cadrul de testare există din 1.6, simularea providerilor (mock_provider) din 1.7, iar generarea de configurație pentru resursele importate (-generate-config-out) este încă marcată experimentală. Un bloc check picat produce doar un avertisment, deci nu ține loc de politică.

O refactorizare tipică, cu redenumire și import:

variable "environment" {
  type = string
}

variable "vpc_id" {
  type = string
}

# Redenumire fără distrugere: state-ul urmează noua adresă.
moved {
  from = aws_s3_bucket.logs
  to   = aws_s3_bucket.audit_logs
}

resource "aws_s3_bucket" "audit_logs" {
  bucket = "acme-${var.environment}-audit-logs"

  lifecycle {
    prevent_destroy = true
  }
}

# Resursă creată cândva din consolă, adusă sub Terraform fără recreare.
import {
  to = aws_security_group.bastion
  id = "sg-0a1b2c3d4e5f67890"
}

resource "aws_security_group" "bastion" {
  name        = "bastion"
  description = "Managed by Terraform"
  vpc_id      = var.vpc_id
}

La moved, planul trebuie să arate zero resurse de distrus; un create plus un destroy înseamnă că adresa din from e greșită. La import, atributele descriu resursa așa cum este, nu cum ar fi „mai frumos”: pe aws_security_group, description forțează înlocuirea. Într-un test local, o descriere rescrisă a produs în plan "Managed by Terraform" -> "Bastion SSH access" # forces replacement. Un model care cosmetizează o resursă importată o recreează.

Testele merită cerute de fiecare dată: un fișier .tftest.hcl cu mock_provider "aws" {} și command = plan rulează fără infrastructură și fără credențiale. Pentru configurația de mai sus, testul a avut nevoie și de un bloc override_resource pe resursa importată; fără el, terraform test se oprește cu „Cannot import resources from mock providers”.

Halucinațiile de schemă și ancorarea în registry

Un argument inventat nu trece de terraform validate: pentru un enable_versioning = true pus pe aws_s3_bucket, răspunsul este An argument named "enable_versioning" is not expected here. Limita e la fel de clară: documentația precizează că validate nu verifică servicii remote, cum ar fi state-ul sau API-urile providerului. Știi că sintaxa e validă, nu și ce pățesc resursele existente.

Ca modelul să nu ghicească din date de antrenare vechi, îi dai schema reală. Fără nicio unealtă nouă, terraform providers schema -json descrie exact versiunea de provider instalată și nu conține valori din infrastructură. Varianta integrată este Terraform MCP server, publicat de HashiCorp sub MPL 2.0 și ajuns la versiunea 1.3.0 (26 august 2026): dă modelului acces la documentația curentă a providerilor, la module și la politici din registry. Serverul poate opera și workspace-uri din HCP Terraform, inclusiv aplicarea unui run, dar uneltele distructive sunt dezactivate implicit și cer ENABLE_TF_OPERATIONS=true; lasă variabila cum este. Pentru OpenTofu există un server MCP separat, pentru registrul propriu.

Review de plan Terraform: ce citești înainte de apply

Principiul vine din revizuirea codului de aplicație: botul comentează, omul aprobă. La IaC, planul este artefactul de review: diff-ul de HCL spune ce a scris agentul, planul spune ce se va întâmpla.

Scenariu pedagogic, reprodus local cu providerul aws 6.67.0: scanerul semnalează o instanță RDS necriptată, iar agentul „repară” adăugând o singură linie, storage_encrypted = true. Diff-ul arată impecabil. Planul spune altceva:

  # aws_db_instance.main must be replaced
      ~ storage_encrypted = false -> true # forces replacement

Corecția ar fi șters baza de date și ar fi creat una goală. De aceea planul se salvează, se transformă în JSON și se citește ca document:

terraform plan -input=false -lock-timeout=60s -out=tfplan
terraform show -json tfplan > tfplan.json

# Rezumat fără valori: acțiune, adresă, atributul care forțează înlocuirea
jq -r '.resource_changes[]
  | select(.change.actions != ["no-op"])
  | [(.change.actions | join("+")), .address,
     ((.change.replace_paths // []) | map(join(".")) | join(","))]
  | @tsv' tfplan.json

Rezumatul, pe configurația de test:

delete+create   aws_db_instance.main                      storage_encrypted
create          aws_iam_policy.ci
delete          aws_s3_bucket.old_exports
update          aws_security_group.bastion
create          aws_vpc_security_group_ingress_rule.ssh

Ce cauți, în ordinea riscului, conform formatului JSON al planului:

Documentația explică de ce înlocuirile apar ca două acțiuni: ca orice unealtă să poată căuta delete în listă și să prindă toate situațiile în care un obiect dispare. Un bloc removed cu destroy = false a apărut, în testul local, cu acțiunea forget: resursa iese din state, dar rămâne în cont.

Două reguli completează tabelul. Prima: modelul primește rezumatul, nu JSON-ul brut. Un asistent traduce bine un plan dens într-o evaluare de risc, dar terraform show -json scrie valorile sensibile în clar. Verificat: o variabilă cu sensitive = true apare cu valoarea ei în variables, în planned_values și în resource_changes[].change.after, deși terminalul afișează (sensitive value).

A doua: se aplică exact planul revizuit, cu terraform apply tfplan. Dacă state-ul s-a schimbat între timp, Terraform refuză cu „Saved plan is stale”. Reversul: pentru un plan salvat nu mai cere confirmare, fiindcă tratează fișierul ca aprobare, deci aprobarea trebuie să existe în pipeline, înaintea acelui pas.

Scanare și policy as code în pipeline

Scanerele statice caută în HCL configurări nesigure cunoscute. Policy as code evaluează planul față de regulile organizației tale, pe care niciun scaner generic nu le știe.

HCP Terraform rulează și politici OPA (advisory sau mandatory), iar documentația listează un al treilea cadru, „Terraform policy”, nativ în HCL și aflat în beta.

O politică minimă pentru Conftest, rulată pe planul de mai sus:

package main

# Tipuri care țin date: ștergerea sau înlocuirea cere excepție aprobată.
stateful := {"aws_db_instance", "aws_rds_cluster", "aws_s3_bucket", "aws_dynamodb_table", "aws_ebs_volume"}

deny contains msg if {
	some rc in input.resource_changes
	rc.type in stateful
	"delete" in rc.change.actions
	msg := sprintf("%s: %s pe o resursă cu date", [rc.address, concat("+", rc.change.actions)])
}

deny contains msg if {
	some rc in input.resource_changes
	rc.type == "aws_iam_policy"
	some st in json.unmarshal(rc.change.after.policy).Statement
	st.Effect == "Allow"
	st.Action == "*"
	msg := sprintf("%s: Allow cu Action \"*\"", [rc.address])
}

conftest test tfplan.json întoarce trei eșecuri și cod de ieșire 1: înlocuirea bazei de date, ștergerea bucketului și politica IAM cu *. Regula nu poate fi convinsă de un comentariu bine scris.

Trei limite. Valorile necunoscute la plan nu pot fi evaluate: documentația Trivy avertizează că datele calculate abia la apply pot produce și alarme false, și omisiuni, deci regulile critice pică atunci când nu pot decide. Planul JSON conține secrete: documentația Checkov recomandă scanarea lui doar într-un pipeline securizat. Iar suprimările (#checkov:skip=<id>:<motiv>, # trivy:ignore, fișierul de baseline) sunt decizii umane: un agent căruia i se cere „un pipeline verde” poate adăuga o suprimare în loc să repare problema.

Scanerul însuși e cod străin care rulează în pipeline-ul tău. Pe 19 martie 2026, conform avizului publicat de Aqua, un atacator a folosit credențiale compromise ca să publice o versiune malițioasă de Trivy (0.69.4) și să mute 76 din cele 77 de etichete ale acțiunii trivy-action pe cod care fura credențiale. De aici: jobul de scanare nu primește credențiale de cloud, iar acțiunile se fixează pe SHA-ul complet al commitului, singura cale, după documentația GitHub, de a folosi o acțiune ca versiune imuabilă. Celelalte capcane ale codului generat, de la pachete inexistente la secrete versionate, sunt în ghidul despre codul generat de AI în producție.

State și secrete: ce nu ajunge niciodată în context

Documentația despre datele sensibile e directă: state-ul local este un fișier text care include orice secret definit în configurație, iar sensitive = true doar maschează valoarea în terminal și în interfață. Valoarea rămâne în state și în plan, la îndemâna oricui poate citi fișierele.

De aici, lista lucrurilor care nu ajung în prompt și nici în directorul citit de agent:

• terraform.tfstate, copiile .backup și orice export al state-ului;
• planul salvat (tfplan) și tfplan.json;
• fișierele .tfvars cu valori reale și directorul .terraform/, care poate păstra credențialele backendului;
• cheile și profilurile de cloud ale contului de producție.

State remote, cu blocare. Agentul lucrează pe cod; state-ul stă într-un backend la care mașina lui nu are acces. Pentru S3, blocarea se activează cu use_lockfile = true (varianta cu tabel DynamoDB e marcată ca depreciată), iar documentația recomandă insistent versionarea bucketului. terraform force-unlock rămâne o comandă exclusiv umană.

Secrete care nu se mai scriu deloc. Din Terraform 1.10 există valori și resurse efemere, iar din 1.11 argumente write-only: providerul le folosește, dar ele nu ajung nici în plan, nici în state. OpenTofu le are din versiunea 1.11.

ephemeral "random_password" "db" {
  length  = 32
  special = false
}

resource "aws_secretsmanager_secret" "db" {
  name = "prod/main-db/password"
}

resource "aws_secretsmanager_secret_version" "db" {
  secret_id                = aws_secretsmanager_secret.db.id
  secret_string_wo         = ephemeral.random_password.db.result
  secret_string_wo_version = 1
}

ephemeral "aws_secretsmanager_secret_version" "db" {
  secret_id = aws_secretsmanager_secret_version.db.secret_id
}

resource "aws_db_instance" "main" {
  identifier          = "acme-prod-main"
  engine              = "postgres"
  instance_class      = "db.t4g.medium"
  allocated_storage   = 50
  username            = "app"
  password_wo         = ephemeral.aws_secretsmanager_secret_version.db.secret_string
  password_wo_version = aws_secretsmanager_secret_version.db.secret_string_wo_version
  deletion_protection = true
}

Verificat local: o variabilă cu ephemeral = true nu apare nicăieri în tfplan.json. Capcana: un secret scris ca literal într-un argument write-only apare totuși în JSON, în secțiunea configuration, pentru că face parte din cod. Write-only protejează state-ul, nu depozitul.

OpenTofu adaugă criptarea state-ului și a planului la nivel de client, din versiunea 1.7; documentația avertizează că fișierele criptate nu mai pot fi citite fără cheie.

Ce credențiale vede agentul și cum îi limitezi rețeaua sunt subiectul ghidului despre izolarea agenților de programare. Pentru IaC, regula e una: pe mașina unde agentul scrie HCL nu există nicio identitate care poate modifica producția.

Drift: codul sau realitatea are dreptate?

Drift-ul apare când cineva schimbă infrastructura în afara codului, de regulă în timpul unui incident. La următorul apply, Terraform readuce resursa la valoarea din cod, adică anulează exact intervenția care ține sistemul în picioare.

Detectarea e mecanică și se programează: terraform plan -refresh-only -detailed-exitcode întoarce 0 când state-ul corespunde realității și 2 când există diferențe, iar JSON-ul planului le listează în resource_drift. În HCP Terraform, funcția se numește health assessments și include detectarea drift-ului și validarea continuă a blocurilor check.

Rolurile rămân aceleași. Agentul explică diferența și propune, într-un pull request, HCL-ul care ar codifica schimbarea manuală. Omul decide: codifică intervenția sau revine conștient la cod. Agentul nu „rezolvă” drift-ul cu un apply și nu rulează apply -refresh-only, care rescrie state-ul.

Cine are drept de apply

Regula centrală: agentul propune, pipeline-ul verifică, omul aprobă, iar apply rulează sub o identitate pe care nu o deține nici agentul, nici autorul schimbării.

Tabelul devine real prin trei mecanisme.

Două identități. Jobul de plan folosește un rol doar-citire. Rolul care poate modifica infrastructura există doar pentru jobul de apply, legat de un mediu protejat. În GitHub Actions, un mediu poate avea până la șase revizori obligatorii; ajunge aprobarea unuia, auto-aprobarea se poate interzice, iar secretele mediului nu ajung la job înainte de aprobare. În HCP Terraform, echivalentul este un workspace fără auto-apply: run-ul așteaptă confirmarea unui utilizator cu drept de apply.

jobs:
  plan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write # OIDC către un rol doar-citire
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: hashicorp/setup-terraform@dfe3c3f87815947d99a8997f908cb6525fc44e9e # v4.0.1
        with:
          terraform_version: 1.16.5
          terraform_wrapper: false
      - run: terraform init -input=false
      - run: terraform plan -input=false -lock-timeout=60s -out=tfplan
      - run: terraform show -json tfplan > tfplan.json
      - run: conftest test tfplan.json --policy policy/

  apply:
    needs: plan
    runs-on: ubuntu-latest
    environment: production # revizori obligatorii, rolul de apply
    steps:
      # checkout, setup și preluarea planului salvat mai sus
      - run: terraform apply -input=false tfplan

Scheletul omite autentificarea în cloud, instalarea Conftest și transferul planului între joburi. Planul salvat conține valori în clar, deci stă într-un loc cu acces restrâns, nu ca artefact vizibil oricui poate citi depozitul.

Refuzul în configurația agentului. În Claude Code, de exemplu, reguli deny precum Bash(terraform apply *), Bash(terraform destroy *), Bash(terraform state *) și Read(**/*.tfstate) opresc comenzile și citirile evidente. Documentația produsului spune însă că o regulă Bash acoperă forma obișnuită a comenzii și nu este o graniță de securitate: aceeași comandă lansată prin bash -c sau cu calea completă a binarului nu e oprită. Regulile reduc accidentele; un apply îl oprește efectiv doar absența credențialelor. Gardurile deterministe (hooks, deny rules) sunt lucrate în cursul Claude Code Mastery, iar aceleași reguli merită scrise și în fișierul AGENTS.md al depozitului de infrastructură.

Protecții în resurse. prevent_destroy în blocul lifecycle și protecția la ștergere a providerului (deletion_protection la RDS) transformă o greșeală într-o eroare. Nu țin loc de aprobare, dar adaugă frecare unde trebuie. Principiul general, privilegiul minim pentru agenții cu unelte, este dezvoltat în cursul AI Security și Ethical Engineering.

Terraform sau OpenTofu: ce se schimbă în fluxul cu AI

La 5 octombrie 2026, Terraform este la versiunea 1.16.5 (30 septembrie 2026), distribuit de la 1.6 încoace sub Business Source License 1.1, cu IBM ca licențiator; textul licenței precizează că folosirea internă într-o organizație nu este ofertă concurentă. OpenTofu este la 1.13.1 (1 octombrie 2026), sub MPL 2.0, în administrarea Linux Foundation și proiect CNCF Sandbox din 23 aprilie 2025.

Pentru fluxul de aici, alegerea schimbă puțin: planul JSON, Conftest și împărțirea rolurilor funcționează la fel, iar Checkov listează explicit OpenTofu printre formatele scanate. Se schimbă riscul de amestec. Proiectele evoluează separat: criptarea la client există doar în OpenTofu, iar valorile efemere au apărut în Terraform 1.10 și în OpenTofu abia în 1.11, așa că un model poate propune sintaxă validă doar în celălalt proiect. Remediul: scrii binarul și versiunea în instrucțiunile pentru agent, fixezi required_version și validezi cu binarul care rulează în pipeline.

Listă de control

1. State remote, cu blocare și versionare; niciun state local pe laptopuri.
2. State-ul, planul salvat, tfplan.json și fișierele .tfvars sunt excluse din contextul agentului.
3. Pe mașina agentului nu există credențiale care pot modifica producția.
4. Modelul primește schema reală a providerului, iar HCL-ul generat trece prin fmt, validate și terraform test.
5. Planul se salvează cu -out, se convertește în JSON și se rezumă fără valori.
6. Reviewerul caută ștergeri, înlocuiri, IAM, rețea, drift și valori necunoscute.
7. Scanerul și politica pe plan blochează; rezumatul scris de model doar comentează.
8. Suprimările și excepțiile de la politici au aprobator uman, altul decât autorul.
9. Apply rulează doar planul revizuit, sub o identitate separată, după aprobare într-un mediu protejat.
10. Acțiunile din pipeline sunt fixate pe SHA; jobul de scanare nu are credențiale de cloud.
11. Drift-ul se detectează programat și se reconciliază prin decizia unui om; resursele cu date au prevent_destroy.

Întrebări frecvente

Pot lăsa un agent AI să ruleze terraform apply dacă planul arată bine? Nu în medii cu date reale. Agentul propune și explică; apply rulează în pipeline, pe planul revizuit, sub o identitate pe care agentul nu o are. O singură linie de plan poate ascunde înlocuirea unei baze de date.

Este sigur să dau unui model planul Terraform ca să mi-l explice? Planul text, da: valorile marcate sensibile apar mascate. Planul JSON și fișierul salvat, nu: conțin valorile în clar. Cel mai sigur este un rezumat cu adresa resursei, acțiunea și atributul care forțează înlocuirea.

Mai pot folosi tfsec în 2026? Funcționează, dar nu mai e direcția de dezvoltare: depozitul oficial anunță că tfsec face parte din Trivy, iar ultima versiune e din mai 2025. Pentru un pipeline nou, alege trivy config sau Checkov.

Am nevoie și de Checkov, și de OPA sau Conftest? Fac lucruri diferite. Checkov și Trivy aduc verificări generice de securitate, pe care nu merită să le rescrii. Conftest sau Sentinel exprimă regulile tale: ce resurse nu se șterg, ce etichete sunt obligatorii, ce drepturi IAM sunt interzise.

Fluxul funcționează la fel cu OpenTofu? Da. tofu show -json produce un plan pe care rulează aceleași politici, iar împărțirea rolurilor nu depinde de unealtă. Spune-i agentului cu ce binar și cu ce versiune lucrezi.

Concluzie

Un model scrie HCL mai repede decât un om și nu poartă nicio răspundere pentru ce face acel HCL în cont. Fluxul care ține în producție pleacă de la această asimetrie. Agentul generează module, refactorizări și teste, ancorat în schema reală a providerului. Pipeline-ul transformă propunerea într-un plan, iar planul în fapte verificabile: acțiuni, înlocuiri, drepturi, reguli de rețea. Scanerele și politicile blochează ce se poate decide mecanic, iar omul aprobă ce cere judecată și răspunde pentru apply. State-ul, planul JSON și credențialele de producție rămân în afara contextului agentului.

Surse

• Terraform, versiuni și licență: https://github.com/hashicorp/terraform/releases
• Terraform, formatul JSON al planului: https://developer.hashicorp.com/terraform/internals/json-format
• Terraform, comanda plan: https://developer.hashicorp.com/terraform/cli/commands/plan
• Terraform, date sensibile: https://developer.hashicorp.com/terraform/language/manage-sensitive-data
• Terraform, teste: https://developer.hashicorp.com/terraform/language/tests
• Terraform, backendul S3: https://developer.hashicorp.com/terraform/language/backend/s3
• Terraform MCP server: https://developer.hashicorp.com/terraform/mcp-server
• HCP Terraform, aplicarea politicilor: https://developer.hashicorp.com/terraform/cloud-docs/policy-enforcement
• HCP Terraform, health assessments: https://developer.hashicorp.com/terraform/cloud-docs/workspaces/health
• OpenTofu, versiuni: https://github.com/opentofu/opentofu/releases
• OpenTofu, criptarea state-ului: https://opentofu.org/docs/language/state/encryption/
• CNCF, proiectul OpenTofu: https://www.cncf.io/projects/opentofu/
• Conftest, documentație: https://www.conftest.dev/
• Checkov, scanarea planului: https://www.checkov.io/7.Scan%20Examples/Terraform%20Plan%20Scanning.html
• Trivy, Terraform: https://trivy.dev/docs/latest/guide/coverage/iac/terraform/
• tfsec, migrarea la Trivy: https://github.com/aquasecurity/tfsec
• Aqua Security, avizul GHSA-69fq-xp46-6x23: https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23
• GitHub Docs, medii protejate: https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
• GitHub Docs, fixarea acțiunilor pe SHA: https://docs.github.com/en/actions/reference/security/secure-use
• Claude Code, permisiuni: https://code.claude.com/docs/en/permissions
• Alexey Grigorev, „How I Dropped Our Production Database”: https://aishippingblog.com/p/how-i-dropped-our-production-database

Articol informativ. Sursele au fost consultate la 5 octombrie 2026; versiunile citate (Terraform 1.16.5, OpenTofu 1.13.1, Checkov 3.3.21, Trivy 0.75.0, Conftest 0.71.0, Terraform MCP server 1.3.0) sunt cele publicate la această dată. Fragmentele de cod au fost validate cu Terraform 1.16.5 (fmt, validate, test, plan, show -json; providerii aws 6.67.0 și random 3.9.1; state local construit pentru test, fără apeluri către un cont de cloud), iar politica Rego a fost rulată cu Conftest 0.71.0 pe planul rezultat. Fragmentul YAML urmează documentația GitHub Actions și nu a fost rulat. Scenariile marcate ca pedagogice sunt ilustrative.