Containertechnologie en Kubernetes-orchestratie zijn uitgegroeid tot het fundament van moderne digitale diensten binnen de Nederlandse overheid. De mogelijkheid om applicaties modulair te ontwikkelen, razendsnel uit te rollen en onafhankelijk te schalen, maakt cloud-native architecturen aantrekkelijk voor organisaties die hun dienstverlening willen moderniseren. Tegelijk vraagt deze wendbaarheid om een beveiligingsaanpak die even dynamisch is als de workloads zelf. Wie vertrouwt op traditionele virtuele machines en statische netwerkranden komt tekort zodra pods binnen seconden ontstaan en weer verdwijnen, nodes automatisch worden opgeschaald en componenten binnen gedeelde kernels draaien.
Overheidsinstellingen bewegen bovendien binnen een stevig wettelijke context. De Nederlandse Baseline voor Veilige Cloud, de BIO en NIS2 verplichten aantoonbare beheersmaatregelen rond identiteit, logging, change management en continue risico-evaluatie. Een containercluster waarin onbekende images kunnen draaien, waarin netwerkverkeer onbeperkt mag stromen of waarin logs versnipperd raken, voldoet nooit aan deze eisen. Daarom moet een DevSecOps-team vanaf het eerste ontwerp nadenken over supply-chaincontrole, runtimebescherming, policy-as-code en traceerbare besluitvorming, zodat auditors kunnen verifiëren dat elke workload aan dezelfde norm is getoetst.
In deze gids verbinden we technologische maatregelen aan bestuurlijke governance. We tonen hoe Microsoft Defender for Containers, Azure Kubernetes Service (AKS), Azure Policy en GitOps-patronen elkaar versterken om kwetsbaarheden te signaleren vóórdat ze productie raken, om configuratiedrift onmiddellijk te blokkeren en om incidentrespons te versnellen met rijke forensische data. Het resultaat is een blauwdruk waarmee architecten, platformteams en security officers containers veilig kunnen inzetten zonder innovatie te remmen.
Dit artikel richt zich op cloudarchitecten, platformteams en security officers die containerplatformen ontwerpen en beheren binnen de Nederlandse publieke sector. We verbinden technische controls aan governance-eisen, zodat architectuurkeuzes direct te vertalen zijn naar BIO- en NIS2-bewijslast.
Kwetsbare containerimages blijven de grootste bron van incidenten. Onderzoek van Anchore laat zien dat 76% van de images in productie ten minste één kritieke CVE bevat. Automatiseer daarom image-scans in elke CI/CD-run en forceer een policy die builds met hoge risico’s blokkeert. Defender for Containers integreert rechtstreeks met Azure Container Registry en rapporteert bevindingen terug naar de pipeline, zodat ontwikkelteams direct kunnen bijsturen.
Container Image Security: Supply Chain Risk Management
Containerimages vormen feitelijk de softwareleveringsketen van elk Kubernetes-platform. De beveiligingshouding van een cluster is dus slechts zo sterk als het zwakste base image, de minst onderhouden bibliotheek of het minst gecontroleerde configuratiebestand dat in een image wordt meegekopieerd. Nederlandse overheidsorganisaties die diensten leveren aan burgers moeten er zeker van zijn dat elke laag van die keten aantoonbaar is gecontroleerd. Een goed uitgangspunt is het publiceren van een catalogus met goedgekeurde basisimages, voorzien van lifecycle-eisen en patchritmes. Distroless- of minimal-images reduceren het aanvalsoppervlak omdat shell-binaries en hulpprogramma’s ontbreken die een aanvaller anders direct kan misbruiken. Wanneer het platformteam slechts een beperkt aantal geharde images aanbiedt, kunnen ontwikkelteams nog steeds snel werken maar wordt de kans op vergeten updates drastisch kleiner.
Een catalogus alleen is niet voldoende. Supply-chainrisico’s verschuiven continu doordat nieuwe CVE’s worden gepubliceerd of doordat externe repositories worden gecompromitteerd. Daarom hoort elke imagebuild een gedwongen security-gate te doorlopen. In Azure DevOps of GitHub Actions integreer je Microsoft Defender for Containers of Trivy zodat iedere Docker build automatisch wordt gescand. Bevindingen worden met severity teruggekoppeld naar de pipeline, waarbij kritieke kwetsbaarheden de release blokkeren totdat een patch is toegepast. Vervolgens scant Azure Container Registry dezelfde image opnieuw zodra deze is gepusht en periodiek zolang deze in de registry staat, zodat later ontdekte kwetsbaarheden alsnog worden gesignaleerd. Door scanresultaten te koppelen aan work item-systemen ontstaat traceerbaarheid richting audits: elke kwetsbaarheid krijgt een eigenaar, prioriteit en doorlooptijd.
Integriteit waarborg je door elke image cryptografisch te ondertekenen via Notary v2 of Sigstore Cosign. Een ondertekende image bewijst welke pipeline en welk serviceaccount de build heeft gemaakt en maakt het voor een aanvaller vrijwel onmogelijk om onderweg een malafide variant te injecteren zonder dat de handtekening ongeldig wordt. Admission controllers zoals Gatekeeper of Kyverno controleren tijdens deployment op dezelfde handtekening en weigeren pods die niet aan de policy voldoen. Daarmee ontstaat een gesloten keten van vertrouwen van broncode tot productiecluster.
Toegang tot registries vormt het derde verdedigingsfront. Azure Container Registry gebruikt Azure AD om onderscheid te maken tussen ontwikkelaars die pushrechten nodig hebben, geautomatiseerde release-agents die images moeten ophalen en auditors die alleen leesrechten krijgen. Private endpoints en firewallregels zorgen dat de registry enkel vanuit vastgestelde overheidsnetwerken bereikbaar is, waardoor data-exfiltratie via publieke endpoints onmogelijk wordt. Combineer dit met Customer-Managed Keys voor encryptie in rust en je kunt aantonen dat gevoelige broncode of configuraties versleuteld blijven volgens de eisen van de Nederlandse Baseline voor Veilige Cloud.
Tot slot vraagt supply-chainbeveiliging om continue monitoring. Dashboards die verzadiging van kwetsbaarheden per afdeling tonen, rapportages over gemiddeld patchtempo en automatische meldingen wanneer een image ouder is dan bijvoorbeeld 30 dagen, geven CISO’s inzicht. Door deze indicatoren op te nemen in het reguliere risicorapport richting bestuur wordt containerbeveiliging geen losstaand technisch onderwerp maar een onderdeel van de bredere governancecyclus.
Kubernetes Security Governance: Policy Enforcement en Access Control
Waar images de basis leggen, bepaalt Kubernetes-governance of beveiligingsmaatregelen daadwerkelijk worden afgedwongen. Een AKS-cluster is een dynamisch stelsel van control-planecomponenten, namespaces, secrets, netwerkinterfaces en identiteiten. Zonder heldere kaders groeit zo’n landschap snel uit tot een oncontroleerbare mix van permissies, configuraties en shadow workloads. Begin daarom met een clusterlandingzone waarin baselineconfiguraties zijn vastgelegd als Infrastructure as Code. Denk aan versleutelde etcd-stores, beheerde identiteiten in plaats van serviceprincipals en geautomatiseerde node-upgrades. Door deze instellingen via Azure Policy of Terraform te beheren, detecteer je configuratiedrift direct en kun je aantonen dat elke cluster op dezelfde manier is ingericht.
Vervolgens is podbeveiliging de eerste lijn. De Kubernetes Pod Security Standards bieden drie profielen: Privileged, Baseline en Restricted. Voor applicaties die persoonsgegevens verwerken of kritieke processen ondersteunen, is Restricted de norm. Daarmee verbied je onder meer de hostPID en hostNetwork, schrijfbare root-filesystemen en het draaien als rootgebruiker. Gebruik Gatekeeper, Kyverno of de ingebouwde Pod Security Admission om deze policies als harde controles af te dwingen. Infrastructurele workloads die hogere rechten nodig hebben, worden in aparte namespaces met aanvullende logging en monitoring geplaatst, zodat afwijkend gedrag snel zichtbaar is.
Netwerksegmentatie vormt de tweede lijn. Zonder policies mag elke pod met elke andere pod communiceren, wat laterale beweging bij een compromise eenvoudig maakt. Schrijf daarom netwerkpolicies die verkeer uitsluitend toestaan op basis van labels en namespaces. Applicatielogica wordt gescheiden van beheerpods, terwijl gevoelige databanken alleen verkeer accepteren van specifieke applicatieservices. Voeg egresspolicies toe die outbound verkeer beperken tot bekende eindpunten zoals API’s of messagebrokers, zodat een gecompromitteerde pod niet ongezien data naar het internet kan sturen. In AKS kunnen Azure CNI, Private Link en DDoS Protection worden gecombineerd om verkeer binnen de rijksnetwerken te houden.
Toegang tot de Kubernetes-API vormt de derde verdedigingslijn. Koppel AKS aan Azure AD en maak gebruik van role bindings per namespace. Ontwikkelteams krijgen alleen rechten om workloads binnen hun eigen namespace te beheren, terwijl het platformteam clusterbrede rollen bezit voor infrastructuuronderhoud. Securityteams ontvangen uitsluitend read-only rechten plus toegang tot auditlogs, zodat scheiding van taken (Segregation of Duties) aantoonbaar is. Combineer dit met just-in-time-toegang via Privileged Identity Management, zodat verhoogde rechten automatisch vervallen na afloop van een change.
Tot slot is observability onmisbaar. Defender for Containers streamt auditlogs, kube-audit-events en sysloggegevens naar Microsoft Sentinel of een SIEM naar keuze. Hierdoor kun je detecties bouwen op policy-overtredingen, mislukte authenticaties of pogingen tot privilege-escalatie. Automatiseer response-acties via Logic Apps of SOAR-playbooks, bijvoorbeeld het automatisch isoleren van een namespace, het blokkeren van een serviceaccount of het afdwingen van een nieuwe imageversie zodra een kwetsbaarheid is gedetecteerd. Door deze processen vast te leggen in runbooks en periodiek te testen via tabletop-oefeningen, sluit de operationele praktijk aan op de eisen van de BIO en NIS2.
Containerbeveiliging vraagt om meer dan een set losse tools; het is een samenhangend programma waarin supply-chainintegriteit, clustergovernance en operationele discipline elkaar versterken. Wie images standaardiseert, scans automatiseert en handtekeningen afdwingt, elimineert het grootste deel van de risico’s nog vóórdat workloads in AKS landen. Wie policies, netwerksegmentatie en streng RBAC combineert, zorgt ervoor dat alleen passende workloads überhaupt op het platform mogen draaien. En wie logging, responsplaybooks en rapportages inricht, kan auditors overtuigen dat controles niet alleen op papier bestaan, maar dagelijks functioneren.
Nederlandse overheidsorganisaties die deze aanpak volgen, bouwen aan een containerplatform dat zowel innovatie stimuleert als aantoonbaar voldoet aan de Nederlandse Baseline voor Veilige Cloud, BIO en NIS2. Daarmee ontstaat het vertrouwen dat burgergerichte diensten, registers en gegevensuitwisselingen veilig kunnen schalen op cloud-native infrastructuur zonder concessies te doen aan governance.