Container Security

Wat is containerbeveiliging en waarom is het een eigen discipline?

Containers hebben de manier waarop software wordt ontwikkeld, getest en uitgerold fundamenteel veranderd. Docker en Kubernetes zijn in de afgelopen jaren uitgegroeid tot de standaardtechnologie voor het verpakken en orchestreren van applicaties, van startups tot de grootste Nederlandse financiële instellingen en overheidsorganisaties. De populariteit van containers is goed te begrijpen: ze bieden snelle deployments, consistente omgevingen, efficiënt resourcegebruik en uitstekende schaalbaarheid. Maar de specifieke architectuur van containeromgevingen introduceert ook beveiligingsrisico's die fundamenteel verschillen van traditionele virtuele machines en die een eigen aanpak vereisen.

Container Security omvat alle maatregelen die nodig zijn om containergebaseerde applicaties en de infrastructuur waarop ze draaien te beschermen. Dit omvat de beveiliging van container images voordat ze worden uitgerold, de beveiliging van de runtime-omgeving waarin containers draaien, de beveiliging van het orchestratieplatform (doorgaans Kubernetes), de beveiliging van de netwerkcommunicatie tussen containers, en de beveiliging van de supply chain waarlangs container images worden gebouwd en gedistribueerd. Elk van deze domeinen heeft eigen kwetsbaarheden en vereist specifieke beveiligingscontroles die niet worden gedekt door traditionele endpoint- of netwerkbeveiligingstools.

De groei van container-adoptie is indrukwekkend. Uit onderzoek blijkt dat meer dan 80% van de cloud-native applicatieontwikkeling in 2025 gebruikmaakt van containers, en het gebruik van Kubernetes als orchestratieplatform is in enterprise-omgevingen bijna universeel geworden. Deze brede adoptie betekent dat container-beveiligingsproblemen een enorm aanvalsoppervlak vertegenwoordigen, en dat aanvallers specifiek op zoek gaan naar kwetsbaarheden in container images, Kubernetes-configuraties en container runtime-omgevingen als ingang voor hun aanvallen.

Container image security: kwetsbaarheden in de buildketen

Een container image is het startpunt van elke container-deployment en vormt een kritiek beveiligingspunt dat vaak wordt onderschat. Een container image is opgebouwd uit lagen: een basisimage (doorgaans een Linux-distributie als Alpine, Ubuntu of Debian), aangevuld met applicatiesoftware, dependencies en configuratiebestanden. Elke laag kan kwetsbare softwarecomponenten bevatten: verouderde bibliotheekversies met bekende CVEs, misconfigureerde permissies, hardcoded credentials of achterdeurtjes die expres of per ongeluk zijn ingebouwd.

Container image scanning is de technische controle die image-kwetsbaarheden detecteert door de inhoud van een image te analyseren op bekende kwetsbaarheden in softwarepakketten en bibliotheken. Moderne scanners vergelijken de softwarecomponenten in een image met databases van bekende kwetsbaarheden zoals de National Vulnerability Database (NVD) en leverancierspecifieke advisories, en rapporteren bevindingen inclusief CVSS-ernst, beschikbaarheid van patches en aanbevolen remediatie. De integratie van image scanning in de CI/CD-pipeline, zodat images worden gescand voordat ze worden uitgerold naar productie, is de best practice die aansluit bij de shift-left beveiligingsfilosofie.

Software Composition Analysis (SCA) is een aanvullende techniek die specifiek gericht is op de open source-afhankelijkheden in een container image. De gemiddelde container image bevat tientallen tot honderden open source-pakketten, elk met hun eigen update-cyclus en kwetsbaarheidsgeschiedenis. SCA-tools genereren een Software Bill of Materials (SBOM), een gedetailleerde inventaris van alle softwarecomponenten in een image, die de basis vormt voor risicoassessment en compliance-aantoning. Met de komst van de Cyber Resilience Act (CRA) in de EU worden SBOM-vereisten voor software steeds meer een wettelijke verplichting dan een vrijwillige best practice.

Kubernetes-beveiliging: het orchestratieplatform beveiligen

Kubernetes is veruit het meest gebruikte container-orchestratieplatform en vormt daarmee een hoog-waarde doelwit voor aanvallers. Een Kubernetes-cluster beheert de scheduling, netwerking en levenscyclus van containers op schaal, en een gecompromitteerd Kubernetes-cluster geeft een aanvaller toegang tot alle applicaties en data die in het cluster draaien. De configuratiecomplexiteit van Kubernetes is aanzienlijk, wat ook verklaart waarom Kubernetes-misconfiguraties een van de meest voorkomende oorzaken zijn van cloud-native beveiligingsincidenten.

Role-Based Access Control (RBAC) is een fundamentele beveiligingscontrole in Kubernetes die bepaalt wie welke acties mag uitvoeren op cluster-resources. Overmatig permissieve RBAC-configuraties, waarbij service accounts of gebruikers meer rechten hebben dan nodig, zijn een veelvoorkomende misconfiguratie die de blast radius van een gecompromitteerd account vergroot. Het afdwingen van het least privilege-principe in Kubernetes RBAC, gecombineerd met regelmatige audits van RBAC-configuraties via gespecialiseerde tools, is een basisbeveiligingsnorm voor productie-Kubernetes-clusters.

Pod Security Standards, de opvolger van de verouderde Pod Security Policies in Kubernetes, definiëren drie beveiligingsprofielen voor pods: Privileged, Baseline en Restricted. Het Restricted-profiel dwingt de strengste beveiligingsinstellingen af, waaronder het verbod op privileged containers, het vereisen van read-only root filesystems en het beperken van Linux capabilities. Veel organisaties die Kubernetes gebruiken, hebben hun pods nog niet gemigreerd naar de Restricted-standaard, wat betekent dat containers meer systeemprivileges hebben dan nodig en daarmee een groter risico vormen bij compromis. Een Cloud Security Posture Management (CSPM) oplossing met Kubernetes-ondersteuning kan automatisch de naleving van Pod Security Standards bewaken en afwijkingen signaleren.

Runtime security: bescherming van draaiende containers

Container image scanning en configuratiebeheer zijn preventieve maatregelen die problemen oplossen voordat containers worden gestart. Maar containers in productie zijn ook blootgesteld aan runtime-aanvallen: aanvallers die via een kwetsbaarheid in de applicatie een container binnendringen, kunnen van daaruit proberen te escapen naar de onderliggende host, zich lateraal te bewegen naar andere containers of data te exfiltreren. Runtime security is de beveiligingscontrole die dit soort aanvallen detecteert en blokkeert terwijl de container draait.

Container Runtime Security tools als Falco (open source) en commerciële equivalenten monitoren de systeemaanroepen die containers maken naar de Linux-kernel. Door een basislijn van normaal gedrag te definiëren en runtime-activiteit voortdurend te vergelijken met die basislijn, detecteren ze verdachte gedragingen zoals het starten van onverwachte processen, het aanmaken van netwerkadressen die niet tot het normale communicatiepatroon behoren, het aanpassen van gevoelige bestandssystemen of pogingen tot privilege escalation. Deze detecties kunnen direct leiden tot automatische blokkering van de verdachte container of een alert aan het beveiligingsteam voor onderzoek.

Container escape-aanvallen, waarbij een aanvaller een kwetsbaarheid in de containerisatielaag uitbuit om toegang te krijgen tot de onderliggende host, zijn een van de meest ernstige container-gerelateerde dreigingen. Hoewel dergelijke kwetsbaarheden minder frequent zijn dan applicatie-kwetsbaarheden, zijn ze extreem impactvol: een succesvolle container escape geeft de aanvaller toegang tot alle containers die op dezelfde host draaien. Runtime security, gecombineerd met het consequent updaten van de container runtime en de onderliggende host-kernel, is de effectieve verdediging tegen deze klasse van aanvallen.

Container network security en microsegmentatie

Containernetwerken zijn standaard permissief: tenzij expliciet beperkingen worden opgelegd, kunnen alle containers in een Kubernetes-cluster met elkaar communiceren. Dit is een groot beveiligingsprobleem in productieomgevingen, omdat het een aanvaller die één container heeft gecompromitteerd, de mogelijkheid geeft om vrij door het interne containernetwerk te bewegen en andere services te bereiken. Network Policies in Kubernetes bieden de technische controle om te definiëren welke pods met welke andere pods mogen communiceren, vergelijkbaar met firewall-regels voor containernetwerken.

De implementatie van Network Policies, ook wel microsegmentatie van containernetwerken genoemd, is een best practice die in de meeste productie-Kubernetes-omgevingen wordt aanbevolen maar in de praktijk minder consistent wordt toegepast dan zou moeten. De reden is de operationele complexiteit: het definiëren van Network Policies voor een applicatie met tientallen microservices die elk specifieke communicatiepatronen hebben, vereist grondige kennis van de applicatiearchitectuur en zorgvuldige implementatie om te voorkomen dat legitieme communicatie per ongeluk wordt geblokkeerd. Service mesh-technologieën als Istio en Linkerd vereenvoudigen dit door netwerksegmentatie te integreren in een overkoepelend verkeersbeheerplatform met fine-grained toegangscontrole.

Mutual TLS (mTLS), het wederzijds authenticeren van servicecommunicatie via TLS-certificaten, is een aanvullende beveiligingslaag die service mesh-platformen bieden. In een mTLS-omgeving moeten services niet alleen de identiteit van de server waarmee ze verbinding maken verifiëren, maar ook zichzelf authenticeren met een eigen certificaat. Dit voorkomt dat een gecompromitteerde container legitieme servicenamen kan imiteren om toegang te krijgen tot gevoelige interne services. De implementatie van mTLS in een Kubernetes-cluster via een service mesh is technisch complex maar biedt een significante verbetering in de beveiliging van oost-west-verkeer dat anders onbeschermd is binnen de clusterperimeter.

Supply chain security voor containers

De beveiliging van de software supply chain is een opkomend prioriteitsgebied dat direct van toepassing is op containeromgevingen. De SolarWinds-aanval en soortgelijke supply chain-aanvallen hebben aangetoond dat aanvallers niet altijd direct de doelorganisatie aanvallen, maar de software-leveringsketen compromitteren om bij tientallen of honderden organisaties tegelijkertijd binnen te komen. Voor containeromgevingen betekent dit dat de integriteit van container images, base images en de CI/CD-pipeline die images bouwt, allemaal potentiële aanvalspunten zijn.

Container image signing is een technische maatregel die de integriteit en herkomst van container images garandeert. Tools als Cosign (onderdeel van het Sigstore-project) en Notary bieden de infrastructuur voor het cryptografisch ondertekenen van container images en het verifiëren van handtekeningen bij deployment. Door Kubernetes te configureren om alleen images te accepteren die zijn voorzien van een geldige handtekening van een vertrouwde bron, wordt het risico van het inzetten van kwaadaardige of gecompromitteerde images aanzienlijk verminderd.

De beveiliging van de CI/CD-pipeline zelf is een aanvullende supply chain-beveiligingsmaatregel. Pipelines die container images bouwen, hebben toegang tot gevoelige credentials, productieomgevingen en broncode, wat ze tot een aantrekkelijk doelwit maakt voor aanvallers. Het beveiligen van pipeline-omgevingen met sterke toegangscontroles, het minimaliseren van de permissions van pipeline-service accounts, het scannen van pipeline-scripts op kwetsbaarheden en het implementeren van audit logging van alle pipeline-activiteiten zijn beveiligingscontroles die de meest volwassen container-beveiligingsprogramma's systematisch toepassen en die direct aansluiten bij de bredere supply chain-beveiligingsinitiatieven die worden gepromoot door initiatieven als SLSA (Supply chain Levels for Software Artifacts).

Compliance en container security benchmarks

Container security wordt steeds vaker getoetst in het kader van compliance-audits en beveiligingscertificeringen. Het Center for Internet Security (CIS) publiceert benchmarks voor Docker, Kubernetes en specifieke cloud-managed Kubernetes-diensten als Amazon EKS en Azure AKS. Deze benchmarks bevatten honderden aanbevolen configuratie-instellingen, gedocumenteerd met de rationale, de impact van de maatregel en instructies voor implementatie. Het meten van de compliance met CIS Benchmarks via geautomatiseerde tools geeft een objectief beeld van de beveiligingsvolwassenheid van de containeromgeving.

De NSA en CISA hebben gezamenlijk een hardening guide gepubliceerd voor Kubernetes die specifiek gericht is op het beveiligen van Kubernetes-deployments in gevoelige omgevingen. De aanbevelingen in deze guide, die onder andere betrekking hebben op pod-configuratie, RBAC, netwerksegmentatie en logging, zijn breed van toepassing op commerciële en overheidsomgevingen en gelden als een referentiestandaard voor serieuze containerbeveiliging. Organisaties die containers inzetten in gereguleerde omgevingen of kritieke toepassingen doen er goed aan hun Kubernetes-configuratie systematisch te toetsen aan deze richtlijnen.

De integratie van container security in bredere DevSecOps-processen is de richting die de industrie inslaat. Door beveiligingscontroles te integreren in elk stadium van de container lifecycle, van de keuze van basisimages via de buildpipeline tot runtime-monitoring en incidentrespons, wordt beveiliging een integraal onderdeel van het ontwikkelproces in plaats van een afterthought die wordt aangebracht nadat applicaties al in productie zijn. Een Cybersecurity Risicoanalyse specifiek voor de containeromgeving helpt bij het identificeren van de grootste risico's en het prioriteren van de beveiligingsinvesteringen die de meest directe impact hebben op de beveiligingsposture van de organisatie.

Secrets management in containeromgevingen

Een van de meest veelvoorkomende en gevaarlijke beveiligingsproblemen in containeromgevingen is het onveilig omgaan met secrets: wachtwoorden, API-sleutels, certificaten en andere gevoelige configuratiewaarden die applicaties nodig hebben om te functioneren. De verleiding om secrets direct in container images, Dockerfiles of omgevingsvariabelen te plaatsen is groot omdat het de eenvoudigste aanpak is, maar dit leidt tot ernstige beveiligingsrisico's: secrets in images kunnen worden uitgelezen door iedereen met toegang tot de image registry, en secrets in omgevingsvariabelen kunnen worden blootgesteld via proceslijsten, logfiles of debug-outputs.

Secrets management tools als HashiCorp Vault, AWS Secrets Manager, Azure Key Vault en Kubernetes Secrets (met aanvullende encryptie) bieden de infrastructuur voor veilig beheer van secrets in containeromgevingen. Het principe is dat secrets niet worden hardcoded in images of configuratiebestanden, maar worden opgehaald op het moment dat een container start vanuit een centrale, goed beveiligde secrets store. Dit maakt ook rotatie van secrets eenvoudiger: wanneer een API-sleutel moet worden vervangen, hoeft alleen de waarde in de secrets store te worden bijgewerkt zonder images opnieuw te bouwen of containers opnieuw te starten.

Automated secrets scanning in CI/CD-pipelines is een aanvullende controle die voorkomt dat secrets per ongeluk in de broncode of container images terechtkomen. Tools als GitGuardian, truffleHog en Semgrep scannen git-repositories en buildartifacten op patronen die wijzen op de aanwezigheid van secrets, zoals API-sleutelformaten, verbindingsstrings met ingebedde wachtwoorden en privésleutels. Door deze controles te integreren in de CI/CD-pipeline wordt een secrets-lek tegengehouden voordat het code naar productie bereikt, wat het risico van gecompromitteerde credentials aanzienlijk verkleint ten opzichte van het reactief opruimen van lekken nadat ze zijn ontdekt.

Container security in de praktijk: een implementatieroute

De implementatie van een volwassen container-beveiligingsprogramma verloopt het effectiefst in stappen die aansluiten bij de ontwikkelvolwassenheid van de organisatie. Voor organisaties die net beginnen met containers is de hoogste prioriteit het instellen van image scanning als verplichte stap in de CI/CD-pipeline, gecombineerd met een beleid dat bepaalt welke ernstigheid van kwetsbaarheden een deployment blokkeert. Dit geeft direct inzicht in de beveiligingstoestand van de container images en creëert een duidelijke baseline voor verbetering.

In de tweede fase worden Kubernetes-configuraties getoetst aan beveiligingsbenchmarks en worden de meest kritieke misconfiguraties verholpen. RBAC-configuraties worden geauditeerd en overtollige permissies worden ingetrokken. Pod Security Standards worden geactiveerd voor namespaces die productieapplicaties hosten. Network Policies worden gedefinieerd voor applicaties met gevoelige data of externe toegang. Deze configuratieverbeteringen verlagen het aanvalsoppervlak significant zonder dat er aanpassingen in de applicatiecode zelf nodig zijn.

De derde fase richt zich op runtime security en continu bewaking: het implementeren van runtime security tools die afwijkend containergedrag detecteren, het opzetten van centraliseerde logging van Kubernetes-audit logs en container-events, en het integreren van container-security alerts in het centrale SIEM of SOC-platform. Op dit niveau heeft de organisatie een proactief en reactief container-beveiligingsprogramma dat zowel kwetsbaarheden voor deployment als actieve aanvallen na deployment detecteert en adresseert, en dat de beveiligingsvolwassenheid biedt die nodig is voor kritieke en gereguleerde applicaties in een veeleisende dreigingsomgeving.

Tooling en platformkeuze voor container security

De markt voor container-beveiligingsoplossingen is de afgelopen jaren snel gegroeid en de keuze is aanzienlijk. Aan de ene kant van het spectrum staan gespecialiseerde container-beveiligingsplatformen als Aqua Security, Sysdig, Snyk Container en Twistlock (nu Prisma Cloud van Palo Alto Networks), die een uitgebreide set functies bieden voor image scanning, runtime security, compliance en supply chain security. Aan de andere kant bieden cloudproviders native container-beveiligingsfuncties als AWS ECR image scanning, Azure Defender for Containers en Google Container Analysis die goed integreren met de respectieve cloudplatformen maar beperkter zijn in multi-cloud scenario's.

Open source-alternatieven als Trivy (image scanning en SBOM-generatie), Falco (runtime security), Kube-bench (Kubernetes-configuratie auditing) en OPA/Gatekeeper (policy enforcement) bieden sterke functionaliteit voor organisaties die voorkeur geven aan open source-tooling of die de kosten van commerciële platforms willen vermijden. De nadelen van een open source-only aanpak zijn de hogere integratie- en beheerkosten en het ontbreken van gecentraliseerd beheer en rapportage die commercial platforms standaard bieden.

Bij de selectie van container-beveiligingstools is de diepte van de Kubernetes-integratie een cruciaal criterium. Tools die alleen images scannen maar geen Kubernetes-configuraties bewaken en geen runtime security bieden, dekken slechts een deel van het container-aanvalsoppervlak. De meest effectieve aanpak combineert meerdere lagen: image scanning voor het voorkomen van kwetsbaarheden voor deployment, configuratiemanagement voor het hardenen van de Kubernetes-omgeving, en runtime security voor het detecteren van actieve aanvallen. Of dit wordt gerealiseerd via één geïntegreerd platform of via een combinatie van gespecialiseerde tools, hangt af van de operationele capaciteiten en het beveiligingsbudget van de organisatie. In beide gevallen geldt dat de investeringen in container security terugverdiend worden door het voorkomen van inbreuken die in gecontaineriseerde microservices-omgevingen een veelvoud aan schade kunnen aanrichten vergeleken met traditionele monolithische applicatiearchitecturen, en dat een gestructureerde aanpak van containerbeveiliging de fundering legt voor veilige cloud-native innovatie op de lange termijn.