Infrastructure Governance

Il problema della governance dell'infrastruttura nell'era degli AI agent: l'AI sa scrivere IaC, ma chi governa quello che genera? Basato su un webinar LF Live (Linux Foundation) tenuto da Harness, che presenta la propria piattaforma come soluzione. ¹

Il gap

Ogni tool è forte se preso da solo: ¹ - IaC conosce lo stato dichiarato - Ansible conosce la configurazione - CI/CD conosce cosa eseguire - Security conosce le policy

Nessuno ha la visione d'insieme. Il risultato: drift, multiple sources of truth, policy solo a checkpoint individuali. ¹

Control plane continuo

Non sostituire Terraform o Ansible, dare loro orchestrazione condivisa in un unico control plane: ¹ - Stato desiderato continuamente riconciliato ¹ - Policy enforced in tutto il lifecycle, dal provisioning al retirement dell'infrastruttura ¹ - "Only compliant systems should deploy" ¹ - Vedi Infrastructure as Code (Evoluzione) per il contesto storico

Provisioning (Terraform, OpenTofu, Terragrunt, CDK), configurazione (Ansible) e deployment applicativo diventano spesso tre workflow separati: gli handoff passano tra team, tool, RBAC e audit diversi, e le policy non si possono applicare in modo uniforme. La risposta di Harness non è sostituire Terraform o Ansible ma orchestrarli in un'unica pipeline. ¹

Segnali dal settore

Gli speaker citano alcune mosse coerenti con questa direzione: ¹ - GitHub descrive gli sviluppatori che passano da coder a orchestratori del lavoro generato dall'AI, e ha pubblicato un'architettura di sicurezza per workflow agentici (isolamento degli agent, output vincolati, logging completo) - OpenTofu 1.12 (maggio) aggiunge output leggibile sia da umani sia da macchine (agent) - HashiCorp ha aggiunto in beta a HCP Terraform un policy framework in HCL per applicare policy in più fasi del lifecycle, inclusa l'inizializzazione

Governance dentro la pipeline

La governance non sta accanto al workflow ma dentro: init, scanner statici (Checkov, TFLint e simili), plan, scansioni post-plan, valutazione di policy e costi, approval solo quando serve, apply. I tool possono cambiare; conta che l'infrastruttura non possa cambiare aggirando le policy. ¹

All'approval l'umano non deve ricostruire il contesto leggendo l'output di Terraform: un passaggio da EC2 small a medium dice solo cosa cambia, mentre serve sapere impatto sui costi, esito delle policy, se c'è drift e se la modifica corregge un drift precedente. ¹

Paved paths (golden paths)

Platform team definisce pattern approvati con template, security control, cost constraint e policy ¹
Developer e agent self-service entro i paved paths ¹
"La safe path diventa la easiest path" ¹
Niente ticket Jira con attese di uno o due giorni per infrastruttura che il platform team ha già provisionato 100 volte ¹
Secondo Rohit (principal product manager di Harness per l'IaC management) il gap più grande è tra ciò che il platform team pubblica e ciò che viene consumato: un cliente voleva sapere quali risorse rispettano i paved paths e quali no, con audit delle non conformità da usare per guidare le persone ¹

Agent con contesto

Nell'architettura presentata una richiesta arriva a un agent unificato che la smista ad agent specializzati (delivery, security, remediation, blast radius). Sotto stanno un knowledge graph dell'ambiente, le regole e policy aziendali e una memoria con il contesto dell'organizzazione e dell'utente: "un agent senza contesto può essere potente, un agent con il contesto giusto è utile". Gli agent sono esposti via MCP, così si usano da Cursor o VS Code. ¹

Expert agent: forniti dalla piattaforma, rispondono a domande come "quali workspace richiedono attenzione?" (apply mancanti, workspace in drift, percentuale di risorse drifted) ¹
Worker agent: agent personalizzati con regole proprie per un compito ristretto ¹
Un DevOps agent crea e corregge pipeline e scrive policy OPA secondo template, approvazioni e ambienti dell'organizzazione, non in modo generico ¹
Un security agent: il problema non è trovare vulnerabilità ma passare da detection a prioritizzazione a remediation senza creare un altro backlog manuale. Vulnerabilità, ottimizzazioni di costo e performance restano in backlog perché altre urgenze hanno la precedenza; quando l'agent propone già la modifica la domanda diventa "approvi?" e il throughput sale ¹

Più gli agent diventano capaci, più conta il layer di governance: l'obiettivo è non dover scegliere tra AI potente e infrastruttura sicura. ¹

Drift remediation agentic

Drift detection periodica → identifica risorse drifted a livello attributo ¹
Remediation agent analizza: cloud vs codebase, cos'è cambiato ¹
Due strategie: (a) drift invalido → reset al codebase, (b) drift valido (clickops) → accetta e aggiorna codice ¹
Agent crea PR → human review → merge → pipeline automatica (init/plan/approval/apply) ¹

Lo scopo è che il backlog contenga fix da rivedere invece di problemi da risolvere: è qui che "heal" diventa concreto. Nella demo un worker agent ha corretto tre attributi accettando una modifica fatta in clickops. Bloccare del tutto l'accesso clickops è aspirazionale: il drift capiterà comunque, quindi servono detection auditabile (nel progetto della demo il 42% delle risorse risultava drifted) e un loop chiuso di remediation. ¹

Blast radius analysis

Agent analizza il plan prima dell'apply → risk score (low/medium/high/critical) ¹
Graph view delle risorse coinvolte nel change (create, modificate, eliminate) con rischio per nodo ¹
Arricchisce l'approval con context: cosa cambia, cosa dipende da cosa, qual è il rischio reale ¹
Nella demo: quattro risorse nuove valgono un rischio basso; una modifica che disabilita i public access block e cancella la cifratura server-side riceve 10 su 10. Il punteggio tiene conto di quanto è connesso il nodo, del tipo di risorsa e del tipo di modifica ¹
Il contesto conta: se la risorsa regge un servizio di produzione o un'istanza di dev, e come è collegata alle altre. Alla domanda sulle dipendenze passive (sistemi a valle che reagiscono a dati via Kafka o pub/sub senza API diretta) la risposta è il knowledge graph, che collega i cambi infrastrutturali ai servizi che li consumano ¹

Human in the loop

"Automazione non significa rimuovere umani ovunque. Significa coinvolgerli dove il loro judgement aggiunge valore." (Harness, durante il webinar) ¹

Infrastructure changes possono causare outage → per ora gli umani restano nell'approval. L'obiettivo è arricchire l'approval con context agentic per renderlo sempre più informato, e eventualmente machine-readable per futuri loop automatici. ¹

Vedi anche: AI Agent in DevOps, Infrastructure as Code (Evoluzione), Agentic Testing, Agentic SOC