GitOps a Terraform: Proč je kombinace výkonná

GitOps transformované nasazení aplikací Kubernetes: Git se stává zdrojem Po pravdě řečeno, kontrolor neustále uvádí do souladu požadovaný stav se skutečným, každá změna prochází žádostí o stažení. V roce 2026 se ujímá stejné paradigma pro cloudovou infrastrukturu spravovanou pomocí Terraform, s jedním zásadním rozdílem oproti Tradiční CI/CD: Namísto spouštěcího tlačítka „pusť a zapomeň“ máte a smíření pokračovat který automaticky detekuje a koriguje drifty.

Problém s tradičními pracovními postupy Terraform založenými na GitHub Actions nebo Atlantis e kterým jsem reaktivní: Někdo provede ruční změnu na konzole AWS a nikdo ví to, dokud neproběhne další potrubí. S GitOps pro Terraform, každý nesoulad mezi HCL kódem a skutečným stavem se stává výstrahou – nebo je opraven automaticky na základě nakonfigurované zásady.

Co se naučíte

  • Architektura GitOps pro IaC: model tahu vs model tahu
  • Flux Terraform Controller: instalace, CRD objektu Terraform a sladění
  • Správa stavu Terraform od Kubernetes s backendem S3 a IRSA
  • Spacelift: zásobníky, zásady Rego, RBAC a schvalovací pracovní postupy
  • Detekce posunu: Upozornění Slack/PagerDuty na neoprávněné odchylky
  • Vzor pro kritická prostředí: automatická náprava vs ruční schválení

Pull Model vs Push Model pro IaC

Klíčovým rozdílem mezi GitOps a tradičním CI/CD je model synchronizace. V push model (GitHub Actions, Jenkins), potrubí se spustí při každém potvrzení a „tlačí“ změny do infrastruktury. V vytáhnout model (čistý GitOps), agent běžící uvnitř clusteru nepřetržitě „vytahuje“ požadovaný stav z úložiště a smířit se. Tento rozdíl má hluboké důsledky pro bezpečnost a odolnost: 

# Push Model (GitHub Actions) — richiede credenziali cloud nella pipeline
# Il runner GitHub deve avere accesso outbound al cloud provider
# Problem: se il job fallisce a meta, lo state puo essere inconsistente

# Pull Model (Flux TF Controller) — l'agente vive dentro il cluster
# Solo il cluster Kubernetes ha le credenziali cloud (via IRSA o Workload Identity)
# Vantaggio: single point of trust, nessuna credenziale nelle GitHub Secrets
# Vantaggio: riconciliazione continua ogni N minuti, non solo su commit

# Confronto security:
# Push Model: GitHub runner --[credenziali]--> AWS/Azure/GCP
# Pull Model: Kubernetes pod -[IRSA/WI]--> AWS/Azure/GCP
#             Git repository -[SSH/HTTPS]--> Flux controller (dentro cluster)

Flux Terraform Controller

Il Flux Terraform Controller (tf-controller) a řadič Kubernetes open-source, který přináší Terraform do světa GitOps. Je to komunitní projekt Flux (Weaveworks + nezávislý správce), který rozšiřuje Flux o schopnost spouštění naplánuje a použije Terraform jako nativní slučovací smyčky Kubernetes.

Instalace

# Prerequisiti: cluster Kubernetes + Flux installato
# Installa Flux sul cluster (se non presente)
flux install

# Installa il TF Controller tramite HelmRelease
cat <<'EOF' | kubectl apply -f -
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: tf-controller
  namespace: flux-system
spec:
  interval: 1h
  url: https://weaveworks.github.io/tf-controller
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: tf-controller
  namespace: flux-system
spec:
  interval: 1h
  chart:
    spec:
      chart: tf-controller
      version: "0.16.x"
      sourceRef:
        kind: HelmRepository
        name: tf-controller
        namespace: flux-system
  values:
    replicaCount: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: 200m
        memory: 512Mi
    # Runner pods: eseguono il processo terraform effettivo
    runner:
      image:
        tag: "v1.5.x-flux"
EOF

# Verifica installazione
kubectl get pods -n flux-system | grep tf-controller
# NAME                                          READY   STATUS    RESTARTS
# tf-controller-6d8f9b4b5-xn7q2               1/1     Running   0

Konfigurace GitRepository a Terraform CRD

Pracovní postup je založen na dvou objektech Kubernetes: a GitRepository který ukazuje na úložiště s kódem HCL a objekt Terraform (CRD vlastní), která definuje co sladit. 

# 1. GitRepository: sorgente del codice HCL
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: infra-repo
  namespace: flux-system
spec:
  interval: 1m          # Controlla il repo ogni minuto
  url: https://github.com/myorg/terraform-infra
  ref:
    branch: main
  secretRef:
    name: github-ssh-key  # Secret con chiave SSH o token

---
# 2. Terraform CRD: definisce il modulo da riconciliare
apiVersion: infra.contrib.fluxcd.io/v1alpha2
kind: Terraform
metadata:
  name: aws-networking
  namespace: flux-system
spec:
  # Intervallo di riconciliazione
  interval: 10m

  # Sorgente HCL
  sourceRef:
    kind: GitRepository
    name: infra-repo
  path: ./environments/prod/networking   # Path nel repo

  # Approvazione automatica (auto-apply) o manuale
  approvePlan: auto

  # Gestione del drift: se lo stato reale differisce dal desired
  # force: riconcilia automaticamente
  # drift: solo alert, non corregge
  enableInventory: true

  # Backend per lo state (S3 con IRSA)
  backendConfig:
    customConfiguration: |
      backend "s3" {
        bucket         = "myorg-terraform-state-prod"
        key            = "networking/terraform.tfstate"
        region         = "eu-west-1"
        dynamodb_table = "terraform-state-lock"
        encrypt        = true
      }

  # Variabili passate al modulo
  vars:
    - name: environment
      value: prod
    - name: aws_region
      value: eu-west-1

  # Variabili da Secret Kubernetes (per segreti)
  varsFrom:
    - kind: Secret
      name: terraform-vars-prod
      varsKeys:
        - db_password
        - api_key

IRSA pro AWS Access od Kubernetes

Doporučené postupy pro ověřování AWS od Kubernetes e IRSA (Role IAM pro servisní účty): Modul Terraform obdrží token JWT podepsaný společností cluster, který je vyměněn s dočasnými přihlašovacími údaji AWS, bez jakéhokoli klíče pevně zakódované do clusteru. 

# Crea il Service Account con annotazione IRSA
kubectl create serviceaccount tf-runner -n flux-system

kubectl annotate serviceaccount tf-runner \
  -n flux-system \
  eks.amazonaws.com/role-arn=arn:aws:iam::123456789:role/TerraformRunnerRole

# IAM Role Trust Policy (da configurare su AWS):
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {
#       "Federated": "arn:aws:iam::123456789:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/..."
#     },
#     "Action": "sts:AssumeRoleWithWebIdentity",
#     "Condition": {
#       "StringEquals": {
#         "oidc.eks.eu-west-1.amazonaws.com/...:sub":
#           "system:serviceaccount:flux-system:tf-runner"
#       }
#     }
#   }]
# }

# Aggiorna il CRD Terraform per usare il Service Account
# Aggiungi nella spec:
# serviceAccountName: tf-runner

Detekce posunu a upozornění

K posunu dochází, když se skutečný stav infrastruktury od toho liší popsané v kódu HCL – obvykle pro ruční změny na cloudové konzoli. TF Controller detekuje odchylku při každém cyklu odsouhlasení a hlásí ji prostřednictvím ho Alert od společnosti Flux. 

# Alert Flux per notifiche Slack sul drift
apiVersion: notification.toolkit.fluxcd.io/v1beta2
kind: Provider
metadata:
  name: slack-infra
  namespace: flux-system
spec:
  type: slack
  channel: "#infra-alerts"
  secretRef:
    name: slack-webhook-url

---
apiVersion: notification.toolkit.fluxcd.io/v1beta2
kind: Alert
metadata:
  name: terraform-drift-alert
  namespace: flux-system
spec:
  providerRef:
    name: slack-infra
  eventSeverity: warning
  eventSources:
    - kind: Terraform
      name: "*"   # Tutti gli oggetti Terraform
  # Invia alert per questi eventi:
  # - drift detected
  # - reconciliation failed
  # - plan pending approval
# Verificare lo stato di drift manualmente
kubectl get terraform -n flux-system
# NAME              READY   STATUS                          AGE
# aws-networking    True    Reconciliation succeeded        2h
# aws-database      False   Drift detected: 3 resources     15m

# Dettaglio del drift
kubectl describe terraform aws-database -n flux-system | grep -A 20 "Conditions:"
# Conditions:
#   Last Transition Time:  2026-03-20T10:30:00Z
#   Message:               Drift detected: aws_db_instance.main (tags changed),
#                           aws_security_group.db (ingress rule added manually)
#   Reason:                TerraformOutputsWritten
#   Status:                False
#   Type:                  Ready

Spacelift: GitOps Enterprise pro Terraform

Spacelift a promyšlenou platformu SaaS (s možností vlastního hostování). pro týmy provozující Terraform v podnikových prostředích. Na rozdíl od TF Controlleru Spacelift, který žije uvnitř clusteru Kubernetes, nabízí komplexní uživatelské rozhraní a pokročilé zásady zapsáno v Rego (stejný jazyk jako OPA), granulární RBAC e schvalovací pracovní postup s kompletním auditním záznamem.

Klíčové koncepty kosmického výtahu

# Struttura Spacelift
# Stack = equivalente di un workspace Terraform
# Ogni stack ha:
# - Source: GitHub/GitLab repository + branch + path
# - Runner image: immagine Docker con Terraform + provider
# - Environment variables: variabili e segreti
# - Policies: regole Rego applicate a plan/apply
# - Contexts: set di variabili condivisibili tra stack

# Creare uno stack via Spacelift API (Terraform provider spacelift):
resource "spacelift_stack" "networking_prod" {
  name        = "networking-prod"
  repository  = "terraform-infra"
  branch      = "main"
  project_root = "environments/prod/networking"

  # Auto-deploy su push al branch
  autodeploy = false   # Per prod: richiede approvazione manuale

  # Terraform version
  terraform_version = "1.9.x"

  labels = ["team:platform", "env:prod", "tier:networking"]
}

resource "spacelift_context_attachment" "networking_prod" {
  context_id = spacelift_context.aws_prod.id
  stack_id   = spacelift_stack.networking_prod.id
  priority   = 1
}

Policy Rego ve Spaceliftu

Zásady Rego jsou silnou stránkou Spaceliftu: umožňují vám definovat zábradlí komplexy, které jsou u každého plánu hodnoceny před rozhodnutím, zda požádat o schválení, blokovat nebo automaticky použít. A v podstatě programovatelná brána. 

# policy: require-approval-for-destructive-changes.rego
# Richiede approvazione umana se il plan contiene distruzioni

package spacelift

# Nega auto-apply se ci sono risorse da distruggere
deny[sprintf("Destroy richiede approvazione: %s", [resource])] {
  change := input.terraform.resource_changes[_]
  change.change.actions[_] == "delete"
  resource := change.address
}

# Blocca completamente se piu di 5 risorse vengono distrutte
deny["Piu di 5 destroy in un singolo plan: richiede approvazione senior"] {
  destroy_count := count([c |
    c := input.terraform.resource_changes[_]
    c.change.actions[_] == "delete"
  ])
  destroy_count > 5
}

# Warn (non blocca) per modifiche ai security group
warn[sprintf("Security group modificato: %s", [resource])] {
  change := input.terraform.resource_changes[_]
  change.type == "aws_security_group"
  change.change.actions[_] != "no-op"
  resource := change.address
}
# policy: cost-control.rego
# Blocca istanze grandi in ambienti non-prod

package spacelift

expensive_instance_types := {
  "m5.4xlarge", "m5.8xlarge", "m5.16xlarge",
  "c5.4xlarge", "c5.9xlarge",
  "r5.4xlarge", "r5.8xlarge"
}

deny[msg] {
  # Leggi i tag dallo stack Spacelift
  not contains(input.spacelift.stack.labels[_], "env:prod")

  # Cerca istanze EC2 con instance_type costoso
  change := input.terraform.resource_changes[_]
  change.type == "aws_instance"
  instance_type := change.change.after.instance_type
  expensive_instance_types[instance_type]

  msg := sprintf(
    "Istanza %s di tipo %s non consentita in ambienti non-prod",
    [change.address, instance_type]
  )
}

Schvalovací pracovní postup Spacelift

# Spacelift approval workflow con notifiche Slack

# 1. Developer fa push al branch feature/add-rds
# 2. Spacelift crea automaticamente un preview run
# 3. La policy Rego valuta il plan: contiene 1 destroy (vecchio RDS)
# 4. Spacelift blocca l'auto-deploy e notifica Slack
#    "Run #abc123 richiede approvazione: destroy aws_db_instance.old_db"
# 5. Senior engineer esamina il plan su Spacelift UI
# 6. Approva cliccando "Confirm" oppure aggiunge commento e rifiuta
# 7. Spacelift esegue l'apply o notifica il developer del blocco

# Via Spacelift CLI (spacectl):
spacectl stack run list --id networking-prod
# ID        COMMIT    STATE           CREATED AT
# abc123    f3a8b91   PENDING_REVIEW  2026-03-20 10:30
# xyz789    a1c2d3e   FINISHED        2026-03-19 14:22

spacectl run confirm --run abc123 --stack networking-prod
# Run abc123 confirmed, applying...

Pokročilá detekce posunu: výstraha a automatická náprava

Detekce driftu nestačí, pokud není doprovázena jasnou strategií reakce. Existují tři přístupy, z nichž každý má své vlastní kompromisy: 

# Approccio 1: Solo Alert (ambienti critici, audit trail necessario)
# Il drift viene rilevato e segnalato, ma non corretto automaticamente
# Uso: database di produzione, networking critico

# Approccio 2: Auto-Remediation per drift minore
# Modifiche ai tag, aggiornamenti di patch: correggi automaticamente
# Blocca e avvisa per modifiche strutturali

# Approccio 3: Full Auto-Apply (ambienti dev/staging)
# Qualsiasi drift viene corretto immediatamente dal controller

---
# Esempio Flux TF Controller: configurazione per approccio ibrido
apiVersion: infra.contrib.fluxcd.io/v1alpha2
kind: Terraform
metadata:
  name: aws-networking-prod
  namespace: flux-system
spec:
  interval: 5m
  approvePlan: "auto"    # "auto" per ambienti non critici

  # Plan runner: genera il piano ma NON lo applica
  # L'apply richiede un secondo passaggio (manuale o automatico)
  planOnly: false

  # Dopo quanti drift consecutivi inviare un alert critico
  # (configurato via Flux Alert con severita error)
  retryInterval: 1m
  timeout: 5m
# Script di scheduled drift check (alternativa leggera senza GitOps controller)
#!/bin/bash
# drift-check.sh — eseguito ogni ora via cron o GitHub Actions scheduled

set -euo pipefail

ENVIRONMENTS=("dev" "staging" "prod")
SLACK_WEBHOOK="${SLACK_DRIFT_WEBHOOK}"

for ENV in "${ENVIRONMENTS[@]}"; do
  cd "/infra/environments/${ENV}"

  # Inizializza senza output
  terraform init -reconfigure -input=false -no-color > /dev/null 2>&1

  # Esegui plan e cattura l'exit code
  # 0 = no changes, 1 = error, 2 = changes detected (drift)
  set +e
  terraform plan -detailed-exitcode -no-color -out=/tmp/plan-${ENV} 2>&1
  EXITCODE=$?
  set -e

  if [ $EXITCODE -eq 2 ]; then
    CHANGES=$(terraform show -no-color /tmp/plan-${ENV} | \
      grep -E "^\s+(#|~|\+|-)" | head -20)

    curl -s -X POST "$SLACK_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{
        \"text\": \"*DRIFT DETECTED* in environment: ${ENV}\n\`\`\`${CHANGES}\`\`\`\"
      }"
    echo "Drift alert sent for ${ENV}"
  elif [ $EXITCODE -eq 0 ]; then
    echo "${ENV}: no drift detected"
  else
    echo "ERROR: terraform plan failed for ${ENV}" >&2
    exit 1
  fi
done

Srovnání: TF Controller vs Spacelift vs Atlantis

Kdy použít který nástroj

  • Regulátor Flux TF: Tým, který již používá Flux/Argo pro Kubernetes, chce čistý a open-source GitOps, spravuje infrastrukturu AWS s IRSA. Samoobslužná, bezplatná, střední křivka učení.
  • Spacelift: Podnikový tým s komplexními požadavky RBAC, audit trail, schvalovací pracovní postup s více schvalovateli, pokročilé zásady Rego. Placené SaaS, skvělé UX, out-of-the-box integrace (Slack, PagerDuty, Jira).
  • Atlantida: Tým, který chce zůstat v paradigmatu založeném na PR bez Čistý GitOps. Plánovat/aplikovat komentovat přímo v PR. Samoobslužný, bezplatný, velmi zralý. Nemá žádné nativní průběžné usmíření.
  • Terraform Cloud/Enterprise: Přirozená volba, pokud již v ekosystému HashiCorp, nativní jazyk politiky Sentinel, integrace Vault. Viz článek 10.

Nejlepší postupy pro GitOps IaC ve výrobě

# Repository structure per GitOps Terraform
terraform-infra/
├── modules/                    # Moduli riusabili (non riconciliati direttamente)
│   ├── networking/
│   ├── compute/
│   └── database/
├── environments/
│   ├── dev/
│   │   ├── networking/         # Stack separati per ogni layer
│   │   │   ├── main.tf
│   │   │   └── terraform.auto.tfvars
│   │   ├── compute/
│   │   └── database/
│   ├── staging/
│   └── prod/
│       ├── networking/         # Ogni ambiente ha il suo state isolato
│       ├── compute/
│       └── database/
├── flux/                       # Manifesti Flux per i CRD Terraform
│   ├── dev/
│   │   ├── networking-tf.yaml
│   │   └── compute-tf.yaml
│   └── prod/
│       ├── networking-tf.yaml  # approvePlan: "auto" o manuale
│       └── compute-tf.yaml
└── policies/                   # Policy Rego (se Spacelift)
    ├── require-approval.rego
    └── cost-control.rego

Anti-Pattern: Usmíření je příliš agresivní

Soubor interval: 1m con approvePlan: auto na prostředích produkční a nebezpečné: změna dosud nezačleněná do hlavního by mohla být uplatněno před revizí. Zlaté pravidlo: čím kritičtější prostředí, tím déle a interval je přísnější a schvalovací proces. V prod použijte interval 30 m+ a vždy vyžadují ruční schválení pro strukturální změny.

Závěry a další kroky

GitOps for Terraform představuje vyspělost Infrastructure as Code: už ne potrubí založené na spouštěči, ale průběžné odsouhlasení, žádné další pověření v potrubích ale nativní identity klastru, už ne „kdo provedl tu změnu“, ale auditní záznamy kompletní v Gitu. Flux TF Controller je ideální volbou pro nativní týmy Kubernetes, zatímco Spacelift splňuje podnikové požadavky se svým modulem Rego policy engine.

Kompletní série: Terraform a IaC

  • článek 01 — Terraform from Scratch: HCL, Provider a Plan-Apply-Destroy
  • článek 02 — Navrhování opakovaně použitelných modulů Terraform
  • článek 03 — Terraform State: Vzdálený backend s S3/GCS
  • článek 04 — Terraform v CI/CD: GitHub Actions a Atlantis
  • článek 05 — Testování IaC: Terratest a Terraform Test
  • článek 06 — Zabezpečení IaC: Checkov, Trivy a OPA
  • článek 07 — Terraform Multi-Cloud: AWS + Azure + GCP
  • Článek 08 (tento) — GitOps pro Terraform: Flux TF Controller, Spacelift a Drift Detection
  • článek 09 — Terraform vs Pulumi vs OpenTofu: Srovnání 2026
  • článek 10 — Terraform Enterprise Patterns: Workspace, Sentinel a Team Scaling