[TODO] Lab - Terraform + Cloudflare DNS (IaC e Drift Detection)

Capitolo: Gibson Cap 8 — Risk Management (Configuration Review) Concetti: Infrastructure as Code, Terraform state, drift detection, least privilege (API token)

Obiettivo

#

Gestire come codice (IaC) la zona DNS Cloudflare del tuo blog Hugo con Terraform, e vedere terraform plan rilevare un drift reale tra quello che hai scritto nel .tf e quello che c'è davvero su Cloudflare. Non è un lab giocattolo: lavori sulla tua infrastruttura vera, in modalità sola-lettura per le prime fasi.

Security angle: Configuration Review (cap-08) descrive esattamente questo: confrontare la configurazione corrente con una baseline nota e segnalare le differenze. terraform plan è un configuration compliance scan — la baseline è il tuo codice .tf, lo stato attuale è la zona DNS reale, e il "report" è il diff che Terraform ti mostra.

Career correlation: Terraform/IaC è nello stack DevSecOps (CARRIERA.md). Qui aggiungi anche un pezzo di IAM: il token API Cloudflare che usi va creato con privilegi minimi (least privilege) — un altro concetto Security+ che torna.

Ambiente

#

• La tua zona DNS reale su Cloudflare (dominio del blog Hugo)
• Terraform locale (Mac) — oppure dal Mustache homelab, se vuoi un ambiente isolato dove far girare terraform plan
• Repo git separato dal repo Hugo, per il codice Terraform (.tf, mai lo state)

Fase 1 — Token API e setup Terraform

#

Obiettivo: crea su Cloudflare un API Token (non la Global API Key) scoped a Zone:DNS:Read + Zone:Zone:Read sulla sola zona del blog. Installa Terraform, configura il provider cloudflare/cloudflare e fai terraform init.

Perché un token scoped: è lo stesso principio di least privilege che vedi lato IAM — un token in sola lettura non può fare danni anche se finisce in un log o in un posto sbagliato.

Come sai che hai finito: terraform init scarica il provider senza errori, e un terraform plan con un data source sulla tua zona restituisce dati reali senza errori di autenticazione.

Fase 2 — Importare un record esistente (baseline)

#

Obiettivo: scegli UN record DNS non critico della tua zona (es. un TXT esistente o un CNAME secondario — non l'A record principale del blog). Scrivi a mano la risorsa cloudflare_record corrispondente nel .tf, poi usa terraform import per agganciarla allo state. Fai terraform plan: se il .tf corrisponde esattamente a quello online, deve dire "No changes".

Come sai che hai finito: terraform plan su quel record dice "No changes" — la tua baseline-as-code corrisponde alla realtà.

Fase 3 — Drift detection in azione

#

Obiettivo: vai sulla dashboard Cloudflare e modifica MANUALMENTE quel record (es. cambia il valore del TXT di test). Torna nel terminale e rilancia terraform plan — non hai toccato il .tf, ma Terraform ora mostra una differenza. Quella riga di output (~ update in-place, con valore vecchio e nuovo) è il configuration drift del cap-08.

Come sai che hai finito: hai visto terraform plan segnalare il drift che hai introdotto manualmente, e ti è chiara la frase "il file .tf è la baseline, la dashboard è lo stato live, plan è lo scan".

Fase 4 (opzionale) — Gestire un record nuovo da codice

#

Obiettivo: crea un record DNS completamente nuovo (es. un TXT di test su un sottodominio tipo lab-terraform.tuodominio.it) SOLO scrivendolo nel .tf e applicandolo con terraform apply. Poi rimuovilo (togli il blocco dal .tf e fai apply di nuovo, oppure terraform destroy -target=...).

Per questa fase serve allargare il token a Zone:DNS:Edit — fallo solo quando arrivi qui, e solo sulla zona del blog.

Come sai che hai finito: il record appare/scompare nella dashboard Cloudflare seguendo apply/destroy — hai chiuso il ciclo completo IaC.

Note di sicurezza (da non saltare)

#

• State file: terraform.tfstate contiene i valori delle risorse in chiaro (zone ID, record ID, a volte segreti se passati male). Metti *.tfstate* e .terraform/ nel .gitignore — non devono mai finire su GitHub.
• Credenziali: il token Cloudflare va in una variabile d'ambiente (CLOUDFLARE_API_TOKEN o TF_VAR_...), mai in chiaro nel .tf.
• Least privilege: token read-only per le Fasi 1-3, edit solo per la Fase 4 e solo sulla zona necessaria — lo stesso principio che ritroverai nell'IAM lato cloud (Azure/AWS).

Collegato a

#

• Configuration Review — drift detection applicata alla tua infrastruttura reale
• dns-records — i record che stai gestendo come codice
• mustache-project — possibile ambiente di esecuzione per Terraform, isolato dal Mac