Containers en Kubernetes positioneren zich als het kloppende hart van moderne overheidsplatforms: applicaties worden sneller geleverd, schaalvergroting gebeurt automatisch en updates kunnen meerdere keren per dag worden uitgerold. Diezelfde eigenschappen vergroten echter ook het aanvalsvlak. Een slecht onderhouden base image, een publieke registry zonder controlemomenten of een te ruim toegestane Kubernetes-rol vormt direct een toegangspoort tot persoonsgegevens en kritieke diensten. In een Nederlandse context, waar de Algemene verordening gegevensbescherming, de BIO en de Nederlandse Baseline voor Veilige Cloud richting geven, is containerbeveiliging daardoor geen technisch zijspoor maar een bestuursvraag.
Het gedeelde verantwoordelijkheidsmodel van Azure Kubernetes Service (AKS) maakt dat Microsoft de control plane onderhoudt, terwijl de overheidsorganisatie verantwoordelijk blijft voor identiteit, netwerksegmentatie, workloadconfiguraties en de volledige software supply chain. Zonder expliciet ontwerp voor identiteiten, registries en beveiligingsbeleid ontstaan configuratie-afwijkingen die bij audits direct zichtbaar worden. Bovendien eisen toezichthouders aantoonbare maatregelen tegen supply-chainaanvallen en verplicht NIS2 een voortdurende risicobeoordeling.
Deze gids vertaalt de principes van de Nederlandse Baseline voor Veilige Cloud naar concrete containermaatregelen. Eerst wordt ingegaan op image-hygiëne en ondertekening, daarna op clustergovernance via RBAC, netwerk policies en admission controllers, en tot slot op operationele bewaking, compliance-evidence en incidentrespons. Elk hoofdstuk biedt verhalende richtlijnen die DevSecOps-teams, platformeigenaren en CISO’s helpen om cloud-native innovatie te versnellen zonder concessies te doen aan vertrouwen en transparantie richting burgers en toezichthouders.
Voor DevSecOps-teams, platformowners en CISO’s binnen de rijksoverheid, provincies, gemeenten en ZBO’s die AKS of andere Kubernetes-clusters beheren en daarbij de Nederlandse Baseline voor Veilige Cloud willen naleven met aantoonbaar beleid voor supply chain, identiteiten en operaties.
Onderzoek van meerdere leveranciers toont aan dat een gemiddelde containerimage meer dan honderd bekende kwetsbaarheden bevat. Door image scanning als harde build-gate in elke pipeline op te nemen en resultaten automatisch te koppelen aan change- en releaseprocessen, zorg je dat kwetsbare dependencies nooit in AKS belanden en dat auditlogs direct laten zien welke versies zijn vrijgegeven.
Container image security: basis voor elk cluster
Organisaties die binnen de Nederlandse Baseline voor Veilige Cloud werken, starten containerbeveiliging bij de herkomst van elke laag. Alleen vendor-onderhouden minimal images of door het eigen platformteam gebuild distroless varianten voldoen, omdat de leverancier patchverplichtingen heeft en de attack surface drastisch lager is. Door base images als code te beheren en versiebeheer te koppelen aan changeprocessen, ontstaat er bewijs richting auditors dat een update van het onderliggende besturingssysteem dezelfde governance doorloopt als een reguliere applicatiewijziging. Bovendien maakt een eigen golden image catalogus het mogelijk om downstream teams te verplichten een digitale handtekening en SBOM mee te leveren voordat een image het productiepad betreedt.
Image-hygiëne blijft fragiel zolang een pipeline niet automatisch scant op Common Vulnerabilities and Exposures (CVE’s) en licentierisico’s. Door scanning in te bouwen als compileertijdige gate en de resultaten naar Microsoft Defender for DevOps of Azure DevOps compliance dashboards te sturen, wordt kwetsbaarheidmanagement integraal onderdeel van de release. Wanneer een CVE in een kritieke component zoals OpenSSL wordt gepubliceerd, kan een policy direct alle builds blokkeren totdat de dependency is bijgewerkt. Vervolgens documenteert de pipeline automatisch welke commit, leverancier en ontwikkelaar de fix heeft gemerged, waardoor de ketencontrole van de BIO aantoonbaar blijft.
Het beperken van herkomstbronnen is de volgende verdedigingslaag. Azure Container Registry (ACR) biedt private replicatie, netwerkisolatie met Private Link, diagnostische logging en integratie met Azure AD Conditional Access. Door pushrechten uitsluitend toe te staan aan serviceprincipals die de volledige CI/CD-run hebben doorlopen, voorkom je dat ontwikkelaars buiten de pipeline om images publiceren. Pull requests richting productieclusters kunnen worden beperkt tot een zogenoemde "promote"-actie in GitOps, zodat elke workload traceerbaar is naar een goedgekeurde manifest-versie. Replicatie naar een tweede regio waarborgt continuïteit, terwijl inhoudelijk dezelfde hash behouden blijft voor forensische vergelijking.
Cryptografische signing en attestatie vormen de sluitsteen. Met Notation, Cosign of Docker Content Trust wordt elke image voorzien van een handtekening die alleen door het centrale platformteam wordt beheerd. Admission controllers controleren vervolgens of een workload enkel een image met de juiste sleutel kan starten. Door Supply Chain Levels for Software Artifacts (SLSA) of het Microsoft Secure Supply Chain consumption framework te volgen, koppel je de signing ook aan build provenance: het manifest bevat informatie over gebruikte toolchains, compiler-versies en testresultaten. Dit maakt het voor een auditor mogelijk om te verifiëren dat de code daadwerkelijk uit het bronarchief komt en niet onderweg is gemanipuleerd.
Ook runtime vraagt aandacht. Zelfs wanneer een image schoon lijkt, kunnen nieuwe kwetsbaarheden openbaar worden na productie. Defender for Containers analyseert daarom registries en draaiende pods, vergelijkt hashwaarden met nieuwe CVE’s en genereert automatisch Jira- of Azure Boards-tickets voor het betrokken team. In combinatie met het verplicht documenteren van een patchplan binnen twintig werkdagen, zoals de Nederlandse Baseline verlangt, ontstaat een sluitende cyclus waarin kwetsbaarheden niet alleen worden ontdekt maar ook aantoonbaar worden dichtgezet. Zo groeit image security uit tot een aantoonbaar volwassen proces dat architectuur, operatie en audit verbindt.
Tot slot hoort er een lerende component bij de supply chain. Iedere sprint reviewt het platformteam de SBOM’s, licentie-informatie en kwetsbaarheidsrapporten samen met productowners, zodat keuzes expliciet worden gemaakt en de verantwoordelijkheid niet tussen ontwikkelaars en securityteams in blijft hangen. De uitkomsten worden vastgelegd in het portfoliorapport en vormen input voor nieuwe aanbestedingen en contractuele security-eisen aan leveranciers.
Kubernetes-governance: RBAC, netwerk policies en pod security
Zodra de images betrouwbaar zijn, verschuift de aandacht naar het cluster zelf. Role-Based Access Control (RBAC) is het fundament: overheidsorganisaties definiëren persona’s voor platformbeheerders, applicatieteams, auditors en automatiseringsaccounts. Elke persona krijgt alleen de API-groepen en verb-objecten die nodig zijn om taken uit te voeren. Een developer werkt doorgaans binnen een toegewezen namespace met een rol die deployments, pods en configmaps mag bijwerken, maar geen secrets mag uitlezen. Auditors ontvangen leesrechten op alle namespaces, inclusief het ability om auditlogs op te vragen, terwijl slechts een handvol platformengineers cluster-admin blijven voor noodsituaties. Door RBAC te koppelen aan Microsoft Entra Privileged Identity Management kunnen kritieke rollen slechts tijdelijk worden geactiveerd met multi-factor authenticatie en expliciete goedkeuring.
Netwerksegmentatie binnen het cluster voorkomt dat een compromitterende workload zich vrijelijk kan verplaatsen. Default Kubernetes-netwerken staan alles toe, waardoor een gehackte pod direct databaseverkeer kan afluisteren. Met Calico of Cilium network policies wordt inkomend en uitgaand verkeer vastgelegd per applicatielaag. Een beleid kan bijvoorbeeld beperken dat alleen de front-end namespace verkeer naar de API-laag stuurt, terwijl egress naar internet uitsluitend via een gedeelde outbound gateway verloopt waar TLS-inspectie plaatsvindt. Door policies te beschrijven in Git en te testen in een stagingcluster voordat ze worden uitgerold, ontstaat een gecontroleerd wijzigingsproces dat aansluit op de verandermanagementeisen van de Baseline.
Pod Security Standards (PSS) en de opvolger Pod Security Admission afdwingen dat workloads zich houden aan baselines zoals niet-root draaien, alleen-lezend rootfilesystem en het verwijderen van gevaarlijke Linux-capabilities. Nederlandse organisaties kiezen vaak voor de restricted policy als standaard en gebruiken uitzonderingscatalogi voor systeemcomponenten. Deze catalogus beschrijft waarom een bepaalde daemonset toch meer privileges nodig heeft en welke compenserende controls aanwezig zijn, zodat auditors begrijpen dat het een bewuste keuze is. In AKS kan deze policy centraal worden afgedwongen via Azure Policy of Gatekeeper, waardoor zelfs ontwikkelclusters dezelfde regels toepassen en kennisoverdracht tussen teams wordt vereenvoudigd.
Admission controllers vormen de lijmlaag tussen beleid en uitvoering. Open Policy Agent of Kyverno kan inkomende API-verzoeken verrijken, blokkeren of automatisch aanpassen. Denk aan een regel die controleert of elk deployment een inkoop-ID en informatieveiligheidsclassificatie als label bevat zodat kosten, eigenaarschap en datacategorieën traceerbaar blijven. Een andere regel kan afdwingen dat alleen images met een specifiek registry-tag, bijvoorbeeld "trusted", mogen draaien. Hierdoor is governance niet afhankelijk van conventies maar van afdwingbare logica. Voor overheidsorganisaties die meerdere clusters beheren, is het verstandig om beleid als code te centraliseren in een Git-repository gecombineerd met een CI-pipeline die syntactische validatie, impactanalyse en automatische documentatie uitvoert.
Tot slot hoort identity-integratie nadrukkelijk bij governance. Service accounts in Kubernetes worden gekoppeld aan workload identities in Microsoft Entra ID, zodat pods zonder secrets in de manifesten toegang krijgen tot Key Vault of Storage. Door federated credentials te gebruiken, vervallen statische client secrets die regelmatig uitlekken. Eventual consistency wordt bewaakt via periodic scans en automatische revocation van ongebruikte accounts. Zo ontstaat een governance-architectuur waarin RBAC, netwerk policies, pod security en identity dezelfde taal spreken en consistent rapporteren richting het centrale risicoregister.
Waar meerdere clusters of tenants bestaan, wordt governance aangevuld met service mesh en policy templates. Een service mesh zoals Istio of Linkerd levert mutual TLS, request-level observability en fijnmazige toegangscontrole tussen microservices, wat vooral bij interbestuurlijke ketens essentieel is. Door dezelfde meshpolicy’s via GitOps uit te rollen naar ieder cluster, blijft de posture uniform en kunnen audits eenvoudig aantonen dat encryptie en authenticatie overal actief zijn. Templates zorgen er bovendien voor dat provincies, gemeenten en agentschappen dezelfde kaders toepassen terwijl zij autonomie behouden over hun eigen workloads.
Operationele bewaking, resilience en compliance-evidence
Een volwassen containerprogramma stopt niet bij ontwerp. Operationele teams moeten continu aantonen dat de ingestelde regels ook daadwerkelijk blijven gelden en dat afwijkingen razendsnel worden gecorrigeerd. Defender for Cloud en Defender for Containers leveren telemetrie over host nodes, clusters en workloads. Deze signalen worden gekoppeld aan Microsoft Sentinel waar use cases draaien voor privilege-escalaties, afwijkende registrypulls en aanpassingen aan network policies. Door deze detecties uit te werken in runbookautomatisering, bijvoorbeeld een Logic App die automatisch een namespace isoleert of een nieuw incident in het gemeentelijke crisismanagementsysteem aanmaakt, ontstaat een aantoonbare responsketen die voldoet aan NIS2 en de BIO-paragraaf over incidentafhandeling.
Runtime-beveiliging omvat ook kwetsbaarheden, geheimen en misconfiguraties die na deployment kunnen ontstaat. Bijvoorbeeld een log4j-bibliotheek die pas later kwetsbaar blijkt. Door continue scanning te combineren met GitOps staat elk manifest tegenover een desired state. Wanneer iemand handmatig een wijziging through kubectl uitvoert, detecteert Flux of Argo CD de drift en zet de gewenste configuratie automatisch terug. Dit levert niet alleen technische bescherming op, maar ook auditbare bewijsvoering: de logging toont wie welke afwijkende actie uitvoerde en hoe snel het platform reageerde. Auditoren kunnen daardoor constateren dat maatregelen niet alleen op papier bestaan, maar in de praktijk worden afgedwongen.
Resilience en continuïteit krijgen een prominente plaats. Voor mission critical workloads eisen Nederlandse overheden dat AKS-clusters minimaal over availability zones zijn verspreid en dat workloads multi-region replicatie voor stateful componenten ondersteunen. Back-ups van etcd worden door Microsoft beheerd, maar de klant borgt applicatiedata via Azure Backup of Velero. Tijdens jaarlijks verplichte hersteltesten tonen teams aan dat container images, secrets, configuraties en data met dezelfde hashwaarden terugkomen. De resultaten worden afgezet tegen de hersteldoelstellingen in het business continuity plan en opgenomen in het jaarverslag informatieveiligheid.
Compliance-evidence is een continu proces. Elk cluster publiceert maandelijks een "security posture rapport" waarin wordt beschreven hoeveel images opnieuw zijn opgebouwd, hoeveel vulnerabilities openstaan, welke policies zijn aangepast en hoe lang incidenten open bleven. Deze rapporten worden gedeeld met de Chief Information Security Officer en de auditdienst. Door Power BI bovenop Log Analytics te zetten, kunnen bestuurders trends volgen: neemt het aantal policy-overtredingen af, hoeveel workloads zijn al naar workload identity federation gemigreerd en hoeveel releases voldoen aan de change lead time die in de Baseline is vastgelegd. Transparantie sluit naadloos aan bij het politieke belang van verantwoording richting burgers en volksvertegenwoordiging.
Tot slot speelt menselijk gedrag een rol. DevSecOps-teams werken binnen communities of practice waarin standaarden, scripts en lessons learned worden gedeeld. Nieuwe teams krijgen onboarding waarbij de standaarden voor containers direct in pipelines zijn voorgeconfigureerd. Hierdoor zijn uitzonderingen daadwerkelijk uitzonderlijk en blijft de totale beheerlast beheersbaar. Een volwassen containeroperatie combineert tooling, processen en cultuur, en maakt daarmee waar dat cloud-native oplossingen sneller én veiliger kunnen worden ingevoerd binnen de Nederlandse overheid.
Om dit alles te borgen, plannen organisaties kwartaalreviews waarin elke cluster-eigenaar de effectiviteit van controls toetst aan het risicodossier en de eisen uit de Nederlandse Baseline voor Veilige Cloud. Daarbij worden scenario’s geoefend, zoals het bewust uitrollen van een kwetsbare image om te testen of de detectieketen aanslaat, of het simuleren van een datacenteruitval waarbij workloads via Infrastructure as Code automatisch in een andere regio worden hersteld. Deze oefeningen leveren concrete verbeteracties op, worden gedeeld met bestuurders en houden iedereen scherp op zijn rol als risicohouder.
Container security en Kubernetes-governance groeien uit tot een integraal onderdeel van de Nederlandse Baseline voor Veilige Cloud. Door image-hygiëne, cryptografische ondertekening, streng RBAC en runtimebewaking te koppelen aan meetbare rapportages, ontstaat een keten waarin elke workload aantoonbaar veilig wordt ontworpen, uitgerold en beheerd. De combinatie van policy-as-code, netwerksegmentatie en workload identities zorgt ervoor dat een incident zich niet ongestoord kan verspreiden en dat herstelprocedures reproduceerbaar zijn.
Het succes hangt af van discipline: elke pipeline voert scans uit, elke registry accepteert alleen getekende images en elke afwijking wordt automatisch gecorrigeerd of onderzocht. Teams die deze werkwijze omarmen, ervaren dat containerplatforms niet alleen sneller zijn, maar ook transparanter richting bestuurders, auditors en burgers. Daarmee wordt Kubernetes een betrouwbare bouwsteen voor digitale diensten van de overheid, in plaats van een ongrijpbaar risico.