Themagids

Infrastructure as code en policy as code

Infrastructure as code beschrijft in bestanden onder versiebeheer welke netwerken, servers en rechten u wilt hebben. Een tool bepaalt hoe u daar komt. Policy as code toetst elke voorgestelde wijziging eerst aan uw regels. Deze gids volgt één wijziging van code tot drift.

main.tfTerraform

resource "aws_security_group" "bastion" {  name   = "bastion"  vpc_id = var.vpc_id   ingress {    from_port   = 22    to_port     = 22    protocol    = "tcp"    cidr_blocks = ["0.0.0.0/0"]  }}

Het JSON-plan is de input van de policy

policy/network.regoOPA Rego

package terraform.network deny contains msg if {  some rc in input.resource_changes  rc.type == "aws_security_group"  some rule in rc.change.after.ingress  rule.from_port <= 22  rule.to_port >= 22  "0.0.0.0/0" in rule.cidr_blocks  msg := sprintf("%s: SSH open to all",    [rc.address])}

Policy check failed: plan not appliedaws_security_group.bastion: SSH open to all

Illustratie: een Terraform-resource en de OPA-regel die hem tegenhoudt.

Zo werkt het

Wat is infrastructure as code, en hoe werkt het?

HashiCorp beschrijft de kernworkflow van Terraform als write, plan en apply. Teams die productie beheren, bouwen daar drie stappen omheen: een policycontrole, een review door een mens en een periodieke driftcontrole. Elke stap laat iets achter dat u kunt inzien.

  1. Schrijven

    *.tf
    # on a branch

    Leg de eindtoestand vast: resources, instellingen en verbindingen. Er verandert nog niets.

  2. Plan

    terraform plan
    -out=tfplan

    Terraform leest wat er bestaat, vergelijkt dat met de code en stelt wijzigingen voor.

  3. Policycontrole

    Gate

    terraform show
    -json tfplan

    Regels lezen het JSON-plan, met de geplande waarden en acties, en keuren overtredingen af.

  4. Review

    Gate

    # pull request
    plan + policy

    Iemand beoordeelt het plan, niet alleen de diff, en begint bij wat er verwijderd wordt.

  5. Apply

    terraform apply
    tfplan

    Het beoordeelde plan wordt uitgevoerd zoals het is opgeslagen. Terraform beschouwt het planbestand als goedkeuring.

  6. Drift opsporen

    terraform plan
    -refresh-only

    Een plan dat periodiek draait, meldt wat er buiten Terraform om is gewijzigd.

Drift gevonden: het herstel begint opnieuw bij 01, in de code.

Illustratie: zes stappen van een infrastructuurwijziging, met twee gates.

Declaratieve state

Waarom heeft Terraform een state file nodig?

Terraform-configuratie is declaratief: ze beschrijft de eindtoestand, niet de stappen. Om te kunnen plannen, moet Terraform weten wat het al heeft gebouwd en welk echt object bij elke resource hoort. Die registratie is de state, en de documentatie van HashiCorp kent die vier taken toe.

Koppeling
Verbindt elke resource in de code met een echt object, zoals een instance-ID.
Metadata
Bewaart afhankelijkheden, zodat verwijderde resources in de juiste volgorde worden opgeruimd.
Prestaties
Houdt attribuutwaarden in een cache bij, zodat grote omgevingen niet bij elke run volledig worden opgevraagd.
Synchronisatie
Met remote state en locking werkt een team vanuit één actuele kopie.

Codemain.tf

aws_security_group.bastion
cidr_blocks = ["0.0.0.0/0"]

Wat u hebt vastgelegd

plan vergelijkt de code met de state

Stateterraform.tfstate

aws_security_group.bastion
id = "sg-0a1b2c3d"

Wat Terraform heeft gebouwd, per adres en ID

refresh leest de echte objecten, apply schrijft het resultaat weg

Echte infrastructuurprovider-API

sg-0a1b2c3d
ingress tcp/22 from 0.0.0.0/0

Wat er werkelijk draait

Illustratie: de state koppelt elke resource aan één echt object.

Behandel de state als een secret

De state wordt als platte tekst opgeslagen, inclusief secrets, en sensitive verbergt alleen waarden in de output. Beperk de toegang tot de backend en versleutel hem, of gebruik de ingebouwde state-encryptie van OpenTofu.

Vergrendel de state

Locking gaat automatisch bij bewerkingen die naar de state schrijven, maar niet elke backend ondersteunt het. Kies er een die dat wel doet, en laat alleen de pipeline een apply uitvoeren.

Splits de state

Eén state voor alles betekent dat elk plan alles leest, en dat elke fout alles kan raken. Splits per eigenaar en naar hoe vaak iets verandert: netwerk, data, applicaties.

De pipeline die dit allemaal uitvoert, heeft zelf ook credentials met ruime rechten; zie Secrets Management in 2026: Sprawl, Non-Human Identities en de Keuze tussen Vault en Workload Identity.

Policy as code

Wat is policy as code, en waar draait het?

Policy as code maakt van regels als “geen SSH vanaf internet” code die een engine bij elke wijziging evalueert. Open Policy Agent (OPA) is een algemeen inzetbare engine. Het is open source en een graduated project van de CNCF. De Rego-policies van OPA kunnen controleren wat Terraform gaat wijzigen, nog voordat het gebeurt. HCP Terraform toetst het plan van elke run aan Sentinel-, OPA- of HCL-policies, die laatste in bèta.

Dezelfde regel kan op drie plekken draaien:

Waar het draaitWat het leestWat het afvangtWat het mist
Vóór de commitEditor of pre-commit-hook, zoals Conftest op .tf-bestanden De broncode Fouten die in de code zichtbaar zijn, op het goedkoopste moment Waarden die pas bij het plan ontstaan. Het draait op een laptop: het adviseert, maar dwingt niets af.
Op het plan, in CIEen verplichte controle tussen plan en apply Het JSON-plan: geplande waarden en acties Wat er echt gaat veranderen, verwijderingen inbegrepen Waarden die pas na de apply bekend zijn, een beperking die de documentatie van OPA noemt. Wijzigingen die buiten de pipeline om gaan.
Bij admissionCloud- of cluster-API: het deny-effect van Azure Policy, OPA Gatekeeper Het verzoek om iets aan te maken of te wijzigen Wijzigingen via elke route, de console inbegrepen Weinig, maar de feedback komt laat, tijdens de apply.

Tools per punt

  • Vóór de commit Conftest draait Rego-policies tegen uw bestanden; Checkov en Trivy, waarin tfsec is opgegaan, scannen met ingebouwde regels op bekende misconfiguraties.
  • Op het plan, in CI OPA of Conftest op het JSON-plan; HCP Terraform toetst elke run aan Sentinel- of OPA-policies.
  • Bij admission Kyverno, met policies in YAML, of OPA Gatekeeper in Kubernetes; Azure Policy in Azure; service control policies in AWS Organizations, die begrenzen wat accounts mogen doen.

CI-stap: policycontroleShell

terraform plan -out=tfplanterraform show -json tfplan > tfplan.jsonopa exec --fail-non-empty \  --decision terraform/network/deny \  --bundle policy/ tfplan.json
Illustratie: de policycontrole als CI-stap.

Met --fail-non-empty faalt de stap bij elke weigering. Maak er een verplichte controle van: het plan geeft het volledigste beeld. Bewaar admissionregels voor wat op elke route moet gelden.

Drift

Wat veroorzaakt configuratiedrift, en hoe voorkomt u dat?

Drift is het verschil tussen de state en de echte infrastructuur. In de drifttutorial van HashiCorp raakt de state door handmatige wijzigingen niet meer synchroon. Meestal begint het met een van deze situaties:

  • Een fix via de console tijdens een incident, die nooit in de code terechtkwam.
  • Een instelling die door een ander systeem wordt beheerd, zoals een autoscaler of een tagging-agent.
  • Twee configuraties of teams die hetzelfde object beheren.

Om drift te vinden, laat u terraform plan -refresh-only periodiek draaien: dat meldt wijzigingen van buitenaf en stelt geen infrastructuurwijzigingen voor. Een normaal plan met -detailed-exitcode geeft bij elk verschil exitcode 2 terug, waarop u eenvoudig een alert kunt instellen. De health assessments van HCP Terraform doen dit voor u.

Preventie betekent dat de pipeline de enige normale route naar productie is: geen permanente schrijfrechten in de console, gelogde break-glass-toegang en admissionregels voor wat nooit mag veranderen. GitOps gaat verder, met agents die continu reconciliëren. Zie GitOps in 2026: reconciliatie, drift en de keuze tussen Argo CD en Flux.

Wijken code en werkelijkheid af, vraag dan:

  1. Een fout, of een fix zonder goedkeuring?

    Terugdraaien Een normaal plan met apply herstelt de vastgelegde waarden.

    terraform apply

  2. Een fix die u wilt behouden?

    Vastleggen Pas de code daarop aan. Een refresh-only apply werkt de state bij, niet de infrastructuur.

    terraform apply -refresh-only

  3. Beheerd door een ander systeem?

    Overdragen ignore_changes laat dat attribuut aan dat systeem over. Elke uitzondering is een blinde vlek.

    ignore_changes = [tags]

  4. Staat het in geen enkele code?

    Importeren Een import-blok brengt het onder beheer, en het plan kan een eerste versie van de configuratie genereren.

    terraform plan
    -generate-config-out=gen.tf

Illustratie: een beslishulp voor elke resource met drift.

Testen

Hoe test u infrastructure as code?

In lagen: van controles die seconden duren en geen credentials nodig hebben, tot tests die echte resources bouwen. Draai de goedkope lagen bij elke commit.

  1. Formatteren en valideren

    Fmt controleert de opmaak. Validate controleert syntaxis, namen en types, en benadert nooit provider-API's of remote state.

    terraform fmt -checkterraform validate

    Seconden, geen credentials

  2. Unittests voor policies

    OPA draait elke regel die met test_ begint, zodat elke policy input krijgt die moet slagen en input die moet falen.

    opa test policy/

    Seconden

  3. Moduletests in plan-modus

    terraform test met mock-providers controleert de logica van een module zonder iets aan te maken of credentials nodig te hebben.

    command = plan

    Seconden tot minuten

  4. Tests in apply-modus

    De standaardmodus bouwt kortlevende resources, controleert de assertions en ruimt de resources daarna weer op. tofu test werkt op dezelfde manier.

    command = apply

    Minuten, sandbox-account

  5. Controles in productie

    Check-blokken waarschuwen zonder te blokkeren, en de continuous validation van HCP Terraform voert ze opnieuw uit.

    check "api_health" {}

    Periodiek

Illustratie: vijf testlagen, de goedkoopste eerst. De balkjes tonen de relatieve kosten per run.

Modulestrategie

Hoe structureert u Terraform-modules het best?

Een module is een verzameling resources die Terraform samen beheert. U voert plan uit in de rootmodule, die de childmodules aanroept. Vier regels dekken het grootste deel van de strategie af.

  1. Benoem een concept, geen resource

    HashiCorp raadt dunne wrappers rond één resourcetype af. Heeft de module dezelfde naam als de resource, gebruik dan de resource zelf.

  2. Houd de boom plat

    HashiCorp raadt sterk aan om bij één niveau childmodules te blijven en afhankelijkheden als input mee te geven.

  3. Pin elke gedeelde module

    Een Git-bron zonder ref gebruikt de standaardbranch. Geef registrymodules een versiebeperking.

  4. Varieer de inputs, niet de code

    Dan draait staging wat straks ook in productie draait, en is promotie een versiewijziging van één regel.

envs/staging/main.tf

module "network" {  source  = "acme/network/aws"  version = "3.2.0"   environment  = "staging"  cidr_block   = "10.20.0.0/16"  nat_gateways = 1}

envs/production/main.tf

module "network" {  source  = "acme/network/aws"  version = "3.2.0"   environment  = "production"  cidr_block   = "10.30.0.0/16"  nat_gateways = 3}
Illustratie: dezelfde module en versie; alleen de gemarkeerde inputs verschillen.

Uit een echte opdracht

Bij Nike ging de provisioning van bots van 45 minuten handwerk naar een self-service flow van ongeveer 3 minuten, en omgevingswijzigingen gingen dezelfde kant op. De stack was Jenkins met Python, Groovy, Ansible en Bash, maar de les geldt net zo goed: één definitie, inputs per omgeving.

Lees de Nike-case
“Previously, moving CI workflows between Dev, Staging, and Prod required manual, uncommitted code changes. Mateusz implemented a solution that reduced this to a single line of code, streamlining the process and enabling faster iteration for both developers and our team.”
Jon V., Mobile Release Engineer Lead, Nike

In gedeelde modules legt een platformteam de standaardwaarden één keer vast; zie Platform Engineering vs DevOps: wat een Internal Developer Platform je echt oplevert.

Valkuilen

Wat zijn de meest voorkomende fouten bij infrastructure as code?

De meeste herkent u eerst aan een vreemd plan.

SymptoomGebruikelijke oorzaakOplossing
Na een hernoeming wil het plan een database vervangen. Voor Terraform betekent een nieuw adres eerst verwijderen, dan aanmaken. Een moved-blok per hernoeming, en prevent_destroy op datastores.
Er duiken secrets op in de state. De state is platte tekst, en sensitive maskeert alleen de output. Versleutel de backend en beperk de toegang. Gebruik ephemeral waarden en write-only-argumenten waar die beschikbaar zijn.
Elk plan toont wijzigingen die niemand heeft gemaakt. Een ander systeem beheert het attribuut, of er worden fixes in de console gedaan. ignore_changes voor instellingen die elders worden beheerd. Leg de rest vast in code of draai die terug.
Na één module-update ligt bij meerdere teams iets stuk. Gedeelde modules die zonder vastgepinde versie worden gebruikt. Pin versies, houd een changelog bij en test voordat u tagt.
Een policy gaf groen licht, maar de resource klopt niet. De waarde was pas bij de apply bekend. Controleer die met een postconditie, of bij admission.

Zelftest

Waar staat uw team?

Tel hoeveel er vandaag kloppen.

  1. De state staat in een remote backend met locking, versleuteling en toegangsbeheer.
  2. Elke wijziging loopt via een pull request, en de pipeline voert het beoordeelde plan uit.
  3. Policies draaien als verplichte controle op het plan, met eigen tests.
  4. Een driftcontrole draait periodiek, en iemand is eigenaar van de alerts.
  5. Niemand heeft permanente schrijfrechten op productie, behalve via break-glass-toegang.
  6. Gedeelde modules zijn vastgepind en worden vóór elke release getest.
  7. De handmatig gemaakte resources die ertoe doen, zijn geïmporteerd.

Waar u begint

Minder dan vier? Begin met de eerste twee. Policy heeft een beoordeeld plan nodig om te lezen, en driftdetectie een state die u vertrouwt.

Veelgestelde vragen

Vragen die engineers stellen

Terraform of OpenTofu?

OpenTofu is een fork van Terraform, ondergebracht bij de Linux Foundation. De fork ontstond nadat HashiCorp in augustus 2023 zijn producten overzette naar de Business Source License. Beide volgen de workflow van write, plan en apply, en OpenTofu gebruikt de providers van Terraform via een eigen registry. Infrastructure as Code in 2026: Drift, Policy en de Keuze tussen Terraform en OpenTofu vergelijkt de twee.

OPA of Sentinel?

Sentinel is het framework van HashiCorp voor policy as code en integreert met HashiCorp-producten zoals Terraform en Vault. OPA is algemeen inzetbaar, dus één taal kan Terraform-plannen, Kubernetes-admission en meer afdekken. HCP Terraform ondersteunt ze allebei. Reiken uw regels verder dan Terraform, dan pleit dat voor één engine voor alles.

Hoe verhoudt dit zich tot GitOps en CI/CD?

CI/CD voert de workflow hierboven uit; zie CI/CD-automatisering. GitOps voegt agents toe die de gewenste toestand ophalen en die continu reconciliëren; zie GitOps. De platforms daaronder komen aan bod bij cloudinfrastructuur.

Gratis Release Check

Bekijk waar uw releases nog op mensen wachten

De Release Check stelt 11 vragen over uw laatste release en laat zien wat dat per jaar kost, met drie verbeteringen. Geen gesprek nodig.

Doe de gratis Release Check