Containers worden in rap tempo omarmd door Nederlandse overheidsorganisaties omdat een cloud-native architectuur grote voordelen biedt. Applicaties kunnen sneller worden uitgerold via onveranderlijke infrastructuur, monolithische systemen worden opgesplitst in beheersbare microservices en DevOps-teams kunnen releases veel frequenter en betrouwbaarder uitvoeren. Tegelijkertijd neemt de afhankelijkheid van Kubernetes toe als feitelijke standaard voor het orkestreren van containerworkloads op schaal. Waar traditionele beveiliging vooral gericht was op virtuele machines en netwerkperimeters, vraagt een Kubernetes‑omgeving om een andere manier van denken over risico’s en controles.
De beveiligingsuitdagingen bij containers zitten in meerdere lagen. Images worden vaak gebouwd op basis van standaard base‑images die verouderde of kwetsbare pakketten kunnen bevatten. Tijdens runtime kan configuratiedrift ontstaan waardoor containers afwijken van het bedoelde beveiligingsniveau. Een gecompromitteerde container kan proberen te ontsnappen naar de onderliggende host, waarna een aanvaller via laterale beweging andere pods en workloads kan bereiken. Daarnaast zijn er risico’s in de software‑keten door het gebruik van third‑party images en afhankelijkheden, en bestaat het gevaar dat geheimen zoals wachtwoorden en certificaten onbeschermd in omgevingsvariabelen of configuratiebestanden terechtkomen.
Incidenten in de praktijk laten zien wat er kan misgaan: cryptomining-aanvallen op verkeerd geconfigureerde clusters die rekenkracht opsouperen, datalekken doordat een kwetsbare applicatiecontainer rechtstreeks toegang heeft tot gevoelige databases, of ransomware die via een container-escape de onderliggende nodes besmet. Azure Kubernetes Service biedt een beheerde Kubernetes‑infrastructuur, maar werkt met een gedeeld verantwoordelijkheidsmodel. Microsoft beveiligt het control plane en het onderliggende platform, terwijl de organisatie zelf verantwoordelijk blijft voor de beveiliging van images, pods, applicatiecode en netwerkconfiguratie. Voor productieomgevingen bij de overheid is daarom een integraal beveiligingsprogramma nodig dat de hele levenscyclus van containers afdekt: van een veilige software supply chain en cluster‑hardening tot toegangscontrole, netwerksegmentatie, geheimenbeheer en continue monitoring. Dit artikel geeft platform engineers en securityteams concrete handvatten om Kubernetes‑workloads op een robuuste en toekomstbestendige manier te beveiligen.
Dit Kubernetes‑beveiligingskader is bedoeld voor teams die verantwoordelijk zijn voor het ontwerpen, beheren en beveiligen van containerplatformen binnen de overheid. Het helpt om het dreigingsmodel van Kubernetes te begrijpen, inzicht te krijgen in de specifieke aanvalsroutes op containers en clusters en deze te vertalen naar concrete technische maatregelen. Onderwerpen zoals image‑security en het scannen van base‑images en afhankelijkheden op kwetsbaarheden, het veilig opbouwen van images met minimale base‑images, niet‑rootgebruikers en read‑only bestandsystemen, het afdwingen van beleid via admission control met Azure Policy en Gatekeeper, het toepassen van pod‑security‑standaarden met beperkte profielen, het segmenteren van verkeer met netwerkpolicies, het integreren van Azure Key Vault voor geheimenbeheer, het inzetten van Defender for Containers voor runtime‑detectie en het uitvoeren van cluster‑hardening op basis van de CIS Kubernetes Benchmark komen stap voor stap aan bod.
Effectieve containerbeveiliging steunt nooit op één enkele maatregel, maar op een gelaagde defense‑in‑depth aanpak. Een praktijkvoorbeeld illustreert dit scherp. Een organisatie had een geavanceerde image‑scan in de CI/CD‑straat ingericht en ging ervan uit dat images zonder bekende kwetsbaarheden automatisch veilig waren. Enkele maanden na uitrol bleek echter dat in een veelgebruikt base‑image een nieuwe, kritieke kwetsbaarheid was ontdekt. De oorspronkelijk gescande images waren destijds schoon, maar draaiende containers bleven ongewijzigd en werden alsnog aangevallen via de nieuw ontdekte CVE. Doordat netwerkpolicies ontbraken, kon de aanvaller zich relatief eenvoudig verplaatsen naar andere pods en uiteindelijk data naar een extern IP-adres exfiltreren.
In de post‑mortem analyse werd duidelijk dat een enkele controle, zoals alleen pre‑deployment scanning, niet voldoende is in een dreigingslandschap waarin zero‑days onvermijdelijk zijn. Er was geen runtime‑bescherming actief die afwijkend gedrag, zoals verdachte procesactiviteit of ongebruikelijke netwerkverbindingen, had kunnen detecteren. Ook ontbraken strikte egress‑regels, waardoor uitgaand verkeer naar onbekende bestemmingen niet werd tegengehouden. De organisatie heeft het beveiligingsontwerp daarna herzien door meerdere lagen te combineren. Image‑scanning bleef een belangrijke eerste drempel voor bekende kwetsbaarheden. Admission control blokkeert nu containers met te ruime privileges of onveilige configuraties. Defender for Containers bewaakt runtime‑gedrag en genereert waarschuwingen bij signalen van exploitatie. Netwerkpolicies beperken het verkeer tussen pods tot strikt noodzakelijke paden en egress‑filtering voorkomt ongecontroleerde uitgaande verbindingen. Daarnaast worden images nu frequenter ververst, zodat patches sneller in productie terechtkomen.
Het resultaat is een veel robuuster beveiligingsmodel waarin het falen van één laag niet direct tot een ernstig incident leidt. Als een zero‑day een image‑scan weet te omzeilen, kunnen runtime‑detectie, netwerksegmentatie en strakke egress‑regels alsnog de impact beperken of het incident volledig voorkomen. De belangrijkste les voor Kubernetes‑omgevingen in de publieke sector is dat er geen “silver bullet” bestaat: alleen een combinatie van complementaire maatregelen biedt de weerbaarheid die nodig is voor bedrijfskritische workloads.
Container image security: bescherming van de softwareketen
Beveiliging van container‑images vormt het fundament van elke Kubernetes‑omgeving, zeker in een overheidscontext waarin vertrouwelijkheid, integriteit en continuïteit zwaar wegen. Een containerimage is in feite een gelaagde bouwtekening van een applicatie: een basislaag met een besturingssysteem, daarop runtime‑componenten zoals .NET, Node.js of Python, vervolgens bibliotheken en afhankelijkheden en ten slotte de eigen applicatiecode. In al deze lagen kunnen kwetsbaarheden aanwezig zijn. Als een image eenmaal in productie draait, wordt elk exemplaar van die image een potentieel aanvalspunt. Daarom moeten organisaties al vóór uitrol in de pipeline systematisch controleren welke kwetsbaarheden en licentierisico’s aanwezig zijn.
In een volwassen aanpak wordt image‑scanning naadloos in de CI/CD‑keten opgenomen. Zodra een ontwikkelaar een nieuwe versie bouwt en naar Azure Container Registry pusht, wordt het image automatisch geanalyseerd. De scanner vergelijkt pakketversies met kwetsbaarheidsdatabases en markeert bekende CVE’s met een ernstniveau. Zo ontstaat een overzicht van kritieke en hoge kwetsbaarheden die direct aandacht vereisen, en lagere risico’s die in een geplande update meegenomen kunnen worden. Tegelijkertijd worden ook configuratiefouten gedetecteerd, zoals containers die als root draaien, images die hard‑gecodeerde geheimen bevatten of onnodig veel netwerkpoorten openstellen. Door rapportage in dashboards en integratie met ticketing‑systemen worden bevindingen zichtbaar voor zowel ontwikkelteams als security officers.
Alleen scannen is echter niet genoeg: de resultaten moeten ook consequent doorwerken in besluitvorming. Een effectieve praktijk is om quality gates in te bouwen in de build‑ en releasepijplijn. Wanneer een image kritieke kwetsbaarheden bevat, wordt de build automatisch afgekeurd of de release naar productie geblokkeerd. Uitzonderingen zijn alleen mogelijk via een expliciet risicobesluit, bijvoorbeeld wanneer een patch nog niet beschikbaar is maar de functionaliteit bedrijfskritisch is. In dat geval wordt vastgelegd waarom het risico tijdelijk wordt geaccepteerd, welke mitigerende maatregelen worden genomen en binnen welke termijn een update wordt doorgevoerd. Zo ontstaat een transparante governance‑structuur rond containerbeveiliging.
Naast het detecteren van kwetsbaarheden is het verkleinen van het aanvalsoppervlak een belangrijk principe. Door te kiezen voor minimale base‑images zonder overbodige tools en pakketten, worden veel potentiële zwakheden simpelweg niet meegeleverd. Multi‑stage builds zorgen ervoor dat tooling die alleen tijdens het buildproces nodig is, niet in het uiteindelijke runtime‑image terechtkomt. Containers draaien idealiter als niet‑rootgebruiker en het bestandssysteem wordt waar mogelijk read‑only gemaakt. Daardoor wordt het voor een aanvaller veel lastiger om bij een geslaagde aanval persistentie in te richten of extra malware te schrijven naar de schijf. Geheimen zoals wachtwoorden, API‑sleutels en certificaten horen niet in een Dockerfile of image thuis, maar worden tijdens runtime via een geheimenbeheeroplossing zoals Azure Key Vault ingeladen.
Om de herkomst en integriteit van images aantoonbaar te maken, zetten steeds meer organisaties image‑signing in. Daarbij wordt elk image cryptografisch ondertekend door de partij die verantwoordelijk is voor de bouw. Tijdens deployment controleert Kubernetes of de handtekening geldig is en of het image afkomstig is van een vertrouwde bron. Dit voorkomt dat een aanvaller ongemerkt een gemanipuleerde image in de registry kan plaatsen en laat uitrollen. In combinatie met een beleid dat alleen images uit goedgekeurde registries toestaat, ontstaat een duidelijke scheiding tussen vertrouwde en onbetrouwbare bronnen. Ten slotte helpt een Software Bill of Materials (SBOM) om grip te houden op alle gebruikte componenten. Wanneer een nieuwe kwetsbaarheid bekend wordt, kan de organisatie via de SBOM snel vaststellen welke images geraakt zijn en gericht updates plannen. Zo wordt image‑security een continu proces in plaats van een momentopname bij de eerste release.
Kubernetes cluster-hardening: CIS Benchmark in de praktijk
Waar image‑security zich richt op de bouwstenen van applicaties, gaat cluster‑hardening over de manier waarop het Kubernetes‑platform zelf is ingericht. Voor overheidsorganisaties is dit cruciaal, omdat het control plane de centrale toegangspoort vormt tot alle workloads en data in het cluster. Een aanvaller die de API‑server weet te misbruiken of misconfiguraties in de clusterconfiguratie uitbuit, kan in korte tijd grote schade aanrichten. De CIS Kubernetes Benchmark biedt een uitgebreide set best practices die organisaties kunnen gebruiken als referentiekader voor een veilig basisontwerp.
Een eerste pijler is de beveiliging van de API‑server en de daaraan gekoppelde authenticatie en autorisatie. In een goed ingericht AKS‑cluster wordt elke API‑aanroep uitgevoerd met een identiteitscontext uit Azure AD. Anonieme toegang wordt volledig uitgeschakeld, zodat er altijd terug te herleiden is welke gebruiker, serviceprincipal of managed identity een wijziging heeft uitgevoerd. Rolgebaseerde toegangscontrole (RBAC) zorgt ervoor dat accounts alleen de minimale set aan rechten krijgen die zij nodig hebben. Een ontwikkelaar die enkel applicaties uitrolt, hoeft geen cluster‑beheerdersrechten te hebben, en een geautomatiseerde pipeline krijgt alleen toegang tot de namespaces waarvoor zij verantwoordelijk is. Door rollen en role bindings zorgvuldig te modelleren, wordt het aanvalsoppervlak bij misbruik van een account sterk verkleind.
Naast deze toegangscontroles speelt netwerktoegankelijkheid een belangrijke rol. In Azure kunnen organisaties de API‑server afschermen door gebruik te maken van private clusters, waarbij de endpoint alleen via interne netwerken bereikbaar is. Indien een publieke endpoint toch nodig is, worden toegestane IP‑reeksen streng beperkt tot beheernetwerken en beheer‑VPN’s. Daarmee wordt voorkomen dat de API‑server rechtstreeks vanaf het internet kan worden benaderd. Uitgebreide auditlogging legt alle API‑verzoeken vast, inclusief de identiteit, het doelobject en het resultaat. Deze logs worden centraal opgeslagen, bijvoorbeeld in Microsoft Sentinel, waar detectieregels afwijkend gedrag kunnen signaleren zoals massale mislukte loginpogingen of ongebruikelijke configuratiewijzigingen buiten kantooruren.
Een tweede belangrijke component van cluster‑hardening is het gebruik van admission controllers om beleid af te dwingen op het moment dat resources worden aangemaakt of gewijzigd. Moderne Kubernetes‑versies gebruiken Pod Security Admission om pod‑security‑standaarden af te dwingen, terwijl Azure Policy als addon kan worden ingezet om organisatiebrede regels toe te passen, zoals het verbieden van bepaalde container‑registries of het verplicht stellen van versleuteling. Met Open Policy Agent Gatekeeper kunnen organisaties eigen regels in Rego beschrijven, bijvoorbeeld dat containers nooit als privileged mogen draaien, dat resource‑limieten verplicht zijn of dat het gebruik van de “latest” imagetag niet is toegestaan. In plaats van alleen achteraf te controleren, wordt onveilige configuratie zo direct bij de voordeur tegengehouden.
De beveiliging van workloads zelf wordt verder versterkt door de Kubernetes Pod Security Standards consequent toe te passen. Door namespaces in te delen naar risicoprofiel kan per categorie workloads een passend beveiligingsniveau worden gekozen. Applicaties die publieke diensten leveren, draaien bij voorkeur in namespaces waar het “Restricted” profiel wordt afgedwongen. Dit betekent onder meer dat containers niet als root mogen draaien, dat host‑resources zoals besturingssysteembestanden en netwerk‑namespaces niet gedeeld worden en dat alleen een minimale set capabilities beschikbaar is. Interne tools of monitoringcomponenten die extra rechten nodig hebben, kunnen in een “Baseline” profiel worden geplaatst, terwijl alleen kritieke systeemcomponenten in uitzonderlijke gevallen een meer bevoorrechte configuratie krijgen. Voor elke uitzondering wordt vastgelegd waarom deze nodig is en welke compenserende maatregelen zijn genomen.
Tot slot speelt netwerksegmentatie een grote rol in het beperken van de impact van een mogelijk incident. Zonder aanvullende maatregelen kan elke pod in principe met elke andere pod communiceren. Door netwerkpolicies in te richten, wordt dit standaardgedrag omgedraaid en wordt alleen nog die communicatie toegestaan die functioneel noodzakelijk is. Een webcomponent krijgt bijvoorbeeld uitsluitend toegang tot de achterliggende applicatielaag, en de applicatielaag mag alleen spreken met de databases in een afgeschermde zone. Cross‑namespaceverkeer wordt beperkt en uitgaand verkeer naar het internet wordt waar mogelijk ingeperkt of via een gecontroleerde uitgang geleid. In combinatie met DNS‑beleid, logging en inspectie van netwerkstromen ontstaat een fijnmazig stelsel dat laterale beweging sterk bemoeilijkt. Cluster‑hardening is daarmee geen eenmalig project, maar een continu verbeterproces waarbij configuraties periodiek tegen de CIS‑benchmark en eigen beleidskaders worden getoetst, zodat het Kubernetes‑platform meegroeit met nieuwe dreigingen en technische ontwikkelingen.
Container- en Kubernetes-beveiliging is een kritieke capability voor Nederlandse overheidsorganisaties die cloud-native applicaties uitrollen. Een robuuste defense-in-depth-aanpak bestrijkt de volledige containerlevenscyclus: van image-scanning en veilige image-opbouw tot cluster-hardening volgens de CIS-benchmark, Pod Security Standards, strikte network policies, runtime-bescherming met Defender for Containers, geheimenbeheer via Key Vault en uitgebreide logging. Het vraagt om platformteams met Kubernetes-beveiligingsexpertise, geautomatiseerde securitytests in CI/CD, policy-as-code en continue compliance-monitoring om configuratiedrift te signaleren.
Organisaties die containerbeveiliging op deze manier implementeren, verminderen hun blootstelling aan kwetsbaarheden, voorkomen exploitatie door geharde configuraties, beperken incidenten door microsegmentatie en detecteren misbruik sneller via runtime-monitoring. Leiderschap is nodig om structureel te investeren in platformbeveiliging, een DevSecOps-cultuur te stimuleren en naleving van beveiligingsstandaarden af te dwingen. Hoewel containerbeveiliging complex is en langdurige aandacht vraagt, stelt het organisaties in staat de voordelen van cloud-native architecturen veilig te benutten binnen de kaders van de Nederlandse Baseline voor Veilige Cloud.