L1/L2 BIO 09.01 ISO A.5.15 CIS CIS Kubernetes Benchmark – Network Policies

Network Policies Voor Azure Kubernetes Service (AKS) – Fundament Van Netwerksegmentatie

📅 2025-01-27
•
⏱️ 25 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Kubernetes Network Policies vormen de ruggengraat van netwerksegmentatie binnen Azure Kubernetes Service-clusters en zijn onmisbaar voor het realiseren van Zero Trust-principes op workloadniveau. In tegenstelling tot traditionele netwerkfirewalls opereren NetworkPolicies op pod- en namespace-niveau, waardoor fijnmazige controle over containercommunicatie mogelijk wordt.

Aanbeveling
IMPLEMENTEER EN HANDHAAF NETWORK POLICIES IN ALLE AKS-CLUSTERS
Risico zonder
High
Risk Score
8/10
Implementatie
130u (tech: 80u)
Van toepassing op:
✓ Azure
✓ Azure Kubernetes Service
✓ Containerized Workloads

Moderne containergebaseerde applicaties bestaan uit tientallen tot honderden microservices die met elkaar moeten communiceren, maar deze communicatie moet strikt worden gecontroleerd om laterale beweging van aanvallers te voorkomen. Zonder NetworkPolicies functioneert een AKS-cluster in de praktijk als één groot vlak netwerksegment: elke pod kan in principe met elke andere pod communiceren, ongeacht de gevoeligheid van de data of de kritiek van de workload. Dit vormt een fundamenteel beveiligingsrisico voor Nederlandse overheidsorganisaties die gevoelige persoonsgegevens verwerken of kritieke diensten leveren. Een compromis van één container kan zich in zo'n omgeving eenvoudig uitbreiden naar andere workloads, wat kan leiden tot datalekken, serviceonderbrekingen en reputatieschade. Bovendien maken ongesegmenteerde clusters het onmogelijk om te voldoen aan compliance-eisen uit de BIO, ISO 27001 en NIS2-richtlijn, waar netwerksegmentatie, minimalisatie van vertrouwensrelaties en controleerbare toegangsregels expliciet worden vereist.

PowerShell Modules Vereist
Primary API: Azure Resource Manager (ARM)
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Resources, Az.Aks, Az.KubernetesService

Implementatie

Dit artikel behandelt het fundament van Kubernetes Network Policies in de context van Azure Kubernetes Service. We beginnen met een diepgaande uitleg van het concept: wat zijn NetworkPolicies precies, hoe verschillen ze van traditionele netwerkbeveiliging, en welke rol spelen ze binnen een Zero Trust-architectuur? Vervolgens behandelen we de verschillende netwerkpolicyproviders die beschikbaar zijn in AKS, zoals Azure CNI Network Policies en Calico, en welke keuzes u moet maken afhankelijk van uw specifieke behoeften en architectuur. We gaan uitgebreid in op het ontwerpen van een effectief netwerksegmentatiemodel: hoe identificeert u trust boundaries, hoe vertaalt u deze naar namespaces en labels, en hoe structureert u NetworkPolicies zodat ze zowel beveiliging als beheerbaarheid waarborgen? Daarnaast behandelen we de praktische aspecten van implementatie, inclusief veelvoorkomende valkuilen, best practices voor policy-ontwerp, en hoe u netwerkpolicies beheert in een organisatie met meerdere teams en leveranciers. Het bijbehorende PowerShell-script helpt u bij het inventariseren van uw huidige situatie en het identificeren van verbetermogelijkheden.

Fundamenten van Kubernetes Network Policies: Concept, architectuur en werking

Kubernetes Network Policies representeren een declaratieve benadering van netwerkbeveiliging op workloadniveau binnen Kubernetes-clusters. In tegenstelling tot traditionele netwerkfirewalls die verkeer filteren op basis van IP-adressen en poortnummers, opereren NetworkPolicies op een hoger abstractieniveau door verkeer te controleren tussen pods op basis van labels, namespaces en andere Kubernetes-primitieven. Dit maakt het mogelijk om beveiligingsregels te definiëren die direct aansluiten bij de logische structuur van applicaties, onafhankelijk van de onderliggende netwerkinfrastructuur. Een NetworkPolicy is in essentie een Kubernetes-resource die specificeert welke pods met welke andere pods of externe endpoints mogen communiceren, en op welke poorten dit verkeer is toegestaan. Wanneer geen NetworkPolicies zijn gedefinieerd, is standaard al het verkeer binnen een cluster toegestaan; zodra echter één NetworkPolicy van toepassing is op een pod, wordt de default-deny regel actief: alleen verkeer dat expliciet is toegestaan door een NetworkPolicy kan plaatsvinden.

De architectuur van Network Policies in AKS is gebaseerd op het Container Network Interface (CNI)-model, waarbij de netwerkpolicyprovider verantwoordelijk is voor het implementeren en handhaven van de gedefinieerde regels. Azure CNI Network Policies maken gebruik van Azure's native netwerkstack en integreren met Azure Virtual Network-functionaliteiten zoals Network Security Groups (NSGs). Deze provider is ideaal voor organisaties die volledig willen vertrouwen op Azure-services en die eenvoudige integratie wensen met bestaande Azure-netwerkbeveiliging. Calico Network Policies daarentegen bieden meer geavanceerde functies zoals globale netwerkpolicies, advanced policy matching op basis van service selectors, en uitgebreide logging en debugging-mogelijkheden. Calico is een open-source project dat wordt gebruikt door veel enterprise Kubernetes-implementaties en biedt extra flexibiliteit voor complexe segmentatiescenario's. De keuze tussen Azure CNI en Calico is fundamenteel en moet worden gemaakt tijdens het aanmaken van het AKS-cluster; het is niet mogelijk om achteraf te wisselen tussen providers zonder het cluster opnieuw te creëren.

NetworkPolicies werken op basis van selectors die pods identificeren aan de hand van labels en namespaces. Een policy kan bijvoorbeeld specificeren dat alle pods met het label 'app=frontend' in de namespace 'production' alleen inkomend verkeer mogen ontvangen van pods met het label 'app=api' in dezelfde namespace, en alleen op poort 8080. Deze declaratieve benadering maakt het mogelijk om beveiligingsregels te definiëren die automatisch meeschalen met de applicatie: wanneer nieuwe pods worden gedeployed met de juiste labels, zijn ze automatisch onderworpen aan dezelfde netwerkbeveiligingsregels. NetworkPolicies ondersteunen zowel ingress- als egress-controle, wat betekent dat u niet alleen kunt bepalen welke inkomend verkeer wordt toegestaan, maar ook welk uitgaand verkeer pods mogen initiëren. Dit is cruciaal voor het voorkomen van data-exfiltratie en het beperken van laterale beweging: zelfs als een aanvaller een pod weet te compromitteren, kan deze pod alleen communiceren met endpoints die expliciet zijn toegestaan in de NetworkPolicies.

Het implementeren van Network Policies vereist een zorgvuldige afweging tussen beveiliging en functionaliteit. Een te restrictieve policy kan leiden tot applicatiefouten wanneer legitieme communicatie wordt geblokkeerd, terwijl een te permissieve policy weinig tot geen beveiligingswaarde biedt. Het is daarom essentieel om een gedegen begrip te hebben van de communicatiepatronen binnen uw applicaties voordat u NetworkPolicies implementeert. Dit vereist vaak een periode van observatie waarin u monitort welke pods met welke andere pods communiceren, op welke poorten, en met welke frequentie. Tools zoals Azure Network Watcher, Azure Monitor en Kubernetes-native logging kunnen helpen bij het in kaart brengen van deze communicatiepatronen. Naast de technische aspecten speelt ook governance een cruciale rol: wie mag NetworkPolicies definiëren en wijzigen, hoe worden wijzigingen getest voordat ze in productie worden gebracht, en hoe wordt geborgd dat alle teams dezelfde segmentatieprincipes volgen? Deze vragen moeten worden beantwoord in architectuurrichtlijnen en changeprocessen voordat u op grote schaal NetworkPolicies implementeert.

Ontwerpen van een effectief netwerksegmentatiemodel voor AKS-workloads

Het ontwerpen van een effectief netwerksegmentatiemodel voor AKS begint met het identificeren van trust boundaries: logische grenzen tussen verschillende functionele domeinen, dataclassificatieniveaus en kritiek van workloads. Voor Nederlandse overheidsorganisaties betekent dit vaak het scheiden van publiek gerichte diensten zoals burgerportalen, interne behandelapplicaties voor ambtenaren, koppelingen met basisregistraties en generieke infrastructuurdiensten zoals monitoring, logging en beheer. Elke trust boundary wordt vertaald naar één of meerdere Kubernetes namespaces, waarbij namespaces dienen als de primaire organisatorische eenheid voor netwerksegmentatie. Binnen een namespace kunnen pods verder worden gegroepeerd en gelabeld op basis van hun functie, bijvoorbeeld 'frontend', 'backend', 'database' of 'cache'. Deze labels vormen de basis voor NetworkPolicy-selectors die bepalen welke pods met elkaar mogen communiceren.

Een goed ontworpen segmentatiemodel volgt het principe van least privilege: pods krijgen alleen de minimale netwerktoegang die nodig is voor hun functie. Frontend-pods in een publieke namespace mogen bijvoorbeeld alleen via gedefinieerde ingress-routes worden benaderd en mogen uitsluitend communiceren met specifieke API-services in een backend-namespace. Deze API-services mogen op hun beurt alleen communiceren met databases in een data-namespace en mogen geen directe uitgaande verbindingen met internet hebben. Beheercomponenten zoals monitoring agents, log collectors en policy controllers verdienen een eigen namespace met zeer beperkte toegang, zodat een compromis van een beheercomponent niet automatisch toegang geeft tot applicatie- of dataworkloads. Het segmentatiemodel moet ook rekening houden met externe afhankelijkheden: welke pods hebben toegang nodig tot Azure-services via private endpoints, welke moeten kunnen communiceren met on-premises systemen via ExpressRoute of VPN, en welke mogen helemaal geen uitgaand verkeer hebben? Door deze vragen vroegtijdig te beantwoorden, voorkomt u dat u later ingrijpende wijzigingen moet doorvoeren in uw NetworkPolicies.

Het definiëren van NetworkPolicies vereist aandacht voor zowel beveiliging als onderhoudbaarheid. Policies die te specifiek zijn op pod-niveau zijn moeilijk te onderhouden en breken snel wanneer pods worden bijgewerkt of vervangen. Policies die te algemeen zijn bieden onvoldoende beveiliging. Een goede vuistregel is om policies te definiëren op basis van functionele rollen (zoals 'frontend', 'backend', 'database') in plaats van individuele pod-namen, en om gebruik te maken van namespace-wide policies waar mogelijk. Het is ook belangrijk om een consistente naamgevingsconventie te hanteren voor labels en namespaces, zodat het voor ontwikkelaars en security engineers duidelijk is welke NetworkPolicies van toepassing zijn op welke workloads. Documentatie is cruciaal: elke NetworkPolicy moet worden gedocumenteerd met een beschrijving van het doel, welke services erdoor worden beïnvloed, en wat de relatie is met architectuurprincipes en compliance-eisen. Deze documentatie helpt bij het begrijpen van het segmentatiemodel tijdens audits en maakt het eenvoudiger om wijzigingen door te voeren zonder onbedoeld beveiligingsregels te verbreken.

Voor organisaties met meerdere teams en leveranciers is het belangrijk om een onderscheid te maken tussen platform policies en applicatie policies. Platform policies worden beheerd door het centrale cloud- of platformteam en zorgen voor basisbescherming zoals het standaard blokkeren van cross-namespace verkeer, het voorkomen van directe uitgaande verbindingen naar internet, en het afdwingen van algemene beveiligingsprincipes. Applicatie policies worden onder regie van de applicatie-eigenaar gedefinieerd binnen de kaders van de platform policies en specificeren de fijnmazige uitzonderingen die nodig zijn voor een specifieke dienst. Deze scheiding van verantwoordelijkheden maakt het mogelijk om snel nieuwe diensten te deployen zonder dat elke wijziging door het platformteam moet worden goedgekeurd, terwijl tegelijkertijd wordt geborgd dat fundamentele beveiligingsprincipes niet worden geschonden. Het is belangrijk om deze rolverdeling vast te leggen in architectuurrichtlijnen en om te zorgen voor voldoende training en documentatie, zodat zowel platform- als applicatieteams effectief kunnen werken met NetworkPolicies.

Implementatie, beheer en operationele aspecten van Network Policies

Gebruik PowerShell-script network-policies.ps1 (functie Invoke-Monitoring) – Inventariseert alle AKS-clusters en rapporteert de netwerkpolicyprovider, actieve NetworkPolicy-objecten en compliance-status voor netwerksegmentatie..

De implementatie van Network Policies in AKS begint met het selecteren van de juiste netwerkpolicyprovider tijdens het aanmaken van het cluster. Voor nieuwe clusters is dit een eenmalige keuze die niet achteraf kan worden gewijzigd zonder het cluster opnieuw te creëren, dus het is belangrijk om deze beslissing zorgvuldig te nemen op basis van uw specifieke behoeften. Azure CNI Network Policies zijn geschikt voor de meeste use cases en bieden eenvoudige integratie met Azure-services. Calico Network Policies zijn aan te raden wanneer u meer geavanceerde functionaliteit nodig heeft of wanneer u al ervaring heeft met Calico in andere Kubernetes-omgevingen. Na het selecteren van de provider moet u Infrastructure as Code (IaC) templates zoals Bicep of Terraform gebruiken om de clusterconfiguratie vast te leggen, zodat nieuwe clusters automatisch de juiste netwerkpolicyprovider hebben en configuratiedrift wordt voorkomen. Het PowerShell-script dat bij dit artikel hoort, kan worden gebruikt om te verifiëren dat alle clusters de juiste provider hebben geconfigureerd.

Het daadwerkelijk definiëren en deployen van NetworkPolicies moet gebeuren via Infrastructure as Code en GitOps-werkflows, waarbij policies worden beheerd als Kubernetes-manifests in versiebeheersystemen. Dit maakt het mogelijk om wijzigingen te reviewen voordat ze worden toegepast, om rollback uit te voeren wanneer problemen optreden, en om een audit trail te behouden van alle wijzigingen in netwerkbeveiligingsregels. Gebruik GitOps-tools zoals Flux of ArgoCD om NetworkPolicies automatisch te synchroniseren naar clusters, zodat configuratiedrift wordt voorkomen en alle omgevingen consistent blijven. Het is belangrijk om NetworkPolicies te testen in niet-productieomgevingen voordat ze naar productie worden gepromoveerd, omdat een verkeerde policy kan leiden tot applicatie-uitval. Maak gebruik van staging-clusters die een kopie zijn van productie-omgevingen om wijzigingen te valideren. Tijdens de implementatiefase is het verstandig om gefaseerd te werk te gaan: begin met policies die expliciet verkeer toestaan (allow-rules) en bouw vervolgens geleidelijk een default-deny model op door policies toe te voegen die specifieke communicatiepaden toestaan terwijl al het overige verkeer wordt geblokkeerd.

Het operationele beheer van Network Policies vereist continue monitoring en onderhoud. Gebruik het PowerShell-script om regelmatig te controleren of alle clusters de juiste netwerkpolicyprovider hebben en of er voldoende NetworkPolicy-objecten zijn gedefinieerd. Monitor ook applicatielogs en metrics om te detecteren wanneer verkeer wordt geblokkeerd door NetworkPolicies, wat kan wijzen op een te restrictieve policy of een onverwachte wijziging in communicatiepatronen. Azure Monitor en Log Analytics kunnen worden gebruikt om query's te maken die NetworkPolicy-gerelateerde gebeurtenissen identificeren, zoals geblokkeerde verbindingen of policy-evaluaties. Het is belangrijk om een proces te hebben voor het behandelen van policy-gerelateerde incidenten: wanneer een applicatie faalt vanwege een NetworkPolicy, moet er snel kunnen worden geïdentificeerd welke policy het probleem veroorzaakt, moet de policy worden aangepast of een uitzondering worden gemaakt, en moet de wijziging worden gedocumenteerd. Voor productieomgevingen is het aanbevolen om een on-call rotatie te hebben van engineers die kennis hebben van zowel de applicaties als de netwerkbeveiligingsconfiguratie, zodat problemen snel kunnen worden opgelost zonder dat beveiliging moet worden uitgezet.

Automatisering is essentieel voor het schalen van Network Policy-beheer over meerdere clusters en teams. Integreer policy-validaties in CI/CD-pijplijnen zodat nieuwe NetworkPolicies automatisch worden gecontroleerd op syntactische correctheid, compliance met architectuurrichtlijnen en mogelijke conflicten met bestaande policies. Gebruik Azure Policy voor Kubernetes om af te dwingen dat alle clusters een minimaal niveau van netwerksegmentatie hebben, bijvoorbeeld door te vereisen dat bepaalde namespaces altijd NetworkPolicies hebben gedefinieerd. Stel ook alerts in die waarschuwen wanneer clusters worden aangemaakt zonder netwerkpolicyprovider of wanneer belangrijke namespaces geen NetworkPolicies hebben. Combineer dit met regelmatige rapportages aan het cloud governance board en de CISO-organisatie, waarin wordt aangegeven welke clusters voldoen aan de netwerksegmentatie-eisen en waar verbeteracties nodig zijn. Door Network Policy-beheer te automatiseren en te borgen in governance-processen, wordt het een duurzaam onderdeel van de Nederlandse Baseline voor Veilige Cloud in plaats van een eenmalig project.

Veelvoorkomende uitdagingen, troubleshooting en best practices

Het implementeren van Network Policies in productieomgevingen gaat vaak gepaard met uitdagingen die zowel technisch als organisatorisch van aard zijn. Een veelvoorkomend probleem is dat applicaties falen nadat NetworkPolicies zijn geïmplementeerd, omdat legitieme communicatie wordt geblokkeerd. Dit gebeurt vaak wanneer de volledige communicatiegrafiek van een applicatie niet goed is begrepen, bijvoorbeeld wanneer applicaties afhankelijk zijn van sidecar-containers, service meshes, of andere infrastructure components die niet direct zichtbaar zijn. Om dit te voorkomen is het essentieel om voorafgaand aan de implementatie een grondige analyse te doen van alle communicatiepatronen, inclusief tijdelijke verbindingen, health checks, en achtergrondprocessen. Gebruik netwerkmonitoring tools om gedurende een periode van minimaal een week alle netwerkverbindingen te loggen, zodat u een compleet beeld krijgt van wat er werkelijk gebeurt voordat u restricties invoert.

Een andere veelvoorkomende valkuil is het creëren van te complexe NetworkPolicies die moeilijk te onderhouden zijn. Wanneer elke pod zijn eigen specifieke policy heeft met unieke selectors en regels, wordt het onmogelijk om overzicht te houden en consistentie te waarborgen. In plaats daarvan moet u streven naar herbruikbare, op rollen gebaseerde policies die van toepassing zijn op groepen van pods met vergelijkbare functies. Gebruik waar mogelijk namespace-wide policies in plaats van pod-specifieke policies, en maak gebruik van label selectors om pods te groeperen op basis van hun functionele rol. Wanneer u merkt dat u veel uitzonderingen moet maken in uw policies, is dit vaak een teken dat uw segmentatiemodel niet goed aansluit bij de werkelijke architectuur van uw applicaties. Overweeg in dat geval om het model te herzien in plaats van steeds meer uitzonderingen toe te voegen.

Troubleshooting van Network Policy-problemen vereist een systematische aanpak. Wanneer een applicatie niet werkt zoals verwacht, moet u eerst verifiëren of NetworkPolicies überhaupt actief zijn op het cluster en of de relevante pods daadwerkelijk zijn geselecteerd door een policy. Gebruik kubectl om de NetworkPolicies in een namespace te inspecteren en om te zien welke labels de pods hebben. Test vervolgens de connectiviteit tussen pods met behulp van kubectl exec om vanuit de ene pod te proberen verbinding te maken met de andere, zodat u kunt zien of verkeer daadwerkelijk wordt geblokkeerd. Logs van de netwerkpolicyprovider (Azure CNI of Calico) kunnen aanvullende informatie geven over waarom specifiek verkeer wordt toegestaan of geblokkeerd. Wanneer u vermoedt dat een policy te restrictief is, kunt u tijdelijk een permissieve policy toevoegen om te testen of dit het probleem oplost, waarna u geleidelijk restricties weer kunt invoeren. Het is belangrijk om dit testproces te documenteren, zodat u later kunt verifiëren welke wijzigingen zijn gemaakt en waarom.

Best practices voor Network Policies in AKS omvatten het volgen van het principe van defense in depth: NetworkPolicies zijn een belangrijke beveiligingslaag, maar moeten worden aangevuld met andere maatregelen zoals pod security policies, RBAC, secrets management en runtime-beveiliging. Begin altijd met het documenteren van uw segmentatiemodel voordat u policies implementeert, zodat alle stakeholders begrijpen welke trust boundaries worden afgedwongen en waarom. Test nieuwe policies altijd eerst in niet-productieomgevingen, en gebruik canary deployments om wijzigingen gefaseerd uit te rollen naar productie. Monitor continu de impact van NetworkPolicies op applicatieperformance, omdat sommige netwerkpolicyproviders overhead kunnen introduceren die de throughput of latency beïnvloedt. Ten slotte, zorg ervoor dat alle betrokken teams voldoende training hebben gekregen in het werken met NetworkPolicies, zodat ze zelfstandig policies kunnen definiëren en troubleshooten binnen de vastgestelde kaders. Door deze best practices te volgen, kunt u het volledige beveiligingspotentieel van Network Policies benutten terwijl u operationele problemen minimaliseert.

Compliance, governance en aansluiting op Nederlandse beveiligingskaders

Gebruik PowerShell-script network-policies.ps1 (functie Invoke-Remediation) – Genereert een overzicht van AKS-clusters zonder netwerkpolicyprovider of met onvoldoende NetworkPolicies, inclusief aanbevelingen voor verbetering en compliance..

Network Policies in AKS vormen een concreet technisch bewijs dat netwerksegmentatie en toegangsbeheersing niet alleen op papier bestaan, maar ook daadwerkelijk zijn geïmplementeerd in de technische infrastructuur. Voor Nederlandse overheidsorganisaties is dit essentieel om te voldoen aan compliance-eisen uit de Baseline Informatiebeveiliging Overheid (BIO), ISO 27001 en de NIS2-richtlijn. Binnen de BIO wordt onder meer verlangd dat logische scheiding van omgevingen en functies aantoonbaar is ingericht en beheerd (BIO-thema 09.01 en 12.02). Door namespaces, labels en NetworkPolicies expliciet te koppelen aan specifieke diensten en processen, kunnen organisaties bij audits helder uitleggen hoe bijvoorbeeld een burgerportaal logisch is gescheiden van interne behandelapplicaties en van generieke infrastructuurdiensten. Het PowerShell-script helpt bij het genereren van auditbewijs door een overzicht te maken van welke clusters netwerksegmentatie hebben geïmplementeerd en welke nog verbetering behoeven.

De NIS2-richtlijn en ISO 27001 benadrukken het belang van technische en organisatorische maatregelen om de impact van beveiligingsincidenten te beperken. Network Policies dragen direct bij aan het beperken van laterale beweging: zelfs wanneer een aanvaller een container weet te compromitteren, is de mogelijkheid om zich verder in de omgeving te verplaatsen beperkt tot de in de policies toegestane paden. Dit maakt het eenvoudiger om aan te tonen dat redelijke maatregelen zijn getroffen om de gevolgen van kwetsbaarheden in applicatiecode, third-party libraries of onderliggende platformcomponenten te mitigeren. In rapportages aan bestuurders en toezichthouders kan worden toegelicht welke segmentatiestrategie is gekozen, hoe deze is geïmplementeerd in AKS via NetworkPolicies, en hoe regelmatig wordt geëvalueerd of deze nog aansluit bij actuele dreigingsbeelden en dienstenportfolio's. Voor organisaties die moeten voldoen aan de CIS Kubernetes Benchmark, vormen Network Policies een directe implementatie van meerdere best practice controles die eisen dat verkeer tussen pods wordt beperkt tot strikt noodzakelijke paden.

Governance van Network Policies vereist een volwassen changeproces waarin wijzigingen worden gereviewed, getest en gedocumenteerd voordat ze in productie worden gebracht. Dit proces moet expliciet vastleggen wie bevoegd is om NetworkPolicies te definiëren en te wijzigen, welke reviewcriteria worden gehanteerd, en hoe uitzonderingen worden behandeld. Voor Nederlandse overheidsorganisaties is het belangrijk dat dit changeproces aansluit bij bestaande governance-structuren en dat alle wijzigingen traceerbaar zijn voor auditdoeleinden. Gebruik versiebeheer en Infrastructure as Code om een complete audit trail te behouden van alle wijzigingen, inclusief de reden voor wijzigingen en wie deze heeft goedgekeurd. Periodieke reviews van het segmentatiemodel zijn essentieel om te waarborgen dat het nog steeds aansluit bij de actuele architectuur en dreigingsbeelden. Tijdens deze reviews kunnen patronen worden herkend: welke organisatieonderdelen lopen structureel achter met het implementeren van NetworkPolicies, waar zijn extra ondersteunings- of opleidingsmaatregelen nodig, en welke generieke bouwblokken of referentie-implementaties ontbreken nog? Door deze informatie te gebruiken voor continue verbetering, wordt Network Policy-configuratie een duurzaam onderdeel van de beveiligingscultuur in plaats van een eenmalig project.

Compliance-monitoring moet regelmatig plaatsvinden om te verifiëren dat alle AKS-clusters voldoen aan de netwerksegmentatie-eisen. Het PowerShell-script kan worden gebruikt als onderdeel van geautomatiseerde compliance-checks die periodiek worden uitgevoerd, bijvoorbeeld wekelijks of maandelijks, en waarvan de resultaten worden gerapporteerd aan het cloud governance board en de CISO-organisatie. Deze rapportages moeten niet alleen aangeven welke clusters compliant zijn en welke niet, maar ook trends laten zien over tijd: neemt het aantal clusters met netwerksegmentatie toe, worden er nieuwe clusters aangemaakt zonder NetworkPolicies, en hoe snel worden niet-compliant clusters geremediateerd? Door deze metrics te volgen, kunnen organisaties hun volwassenheid op het gebied van netwerksegmentatie kwantificeren en gerichte verbeteracties ondernemen. Auditbewijs zoals NetworkPolicy-configuraties, changelogs, compliance-rapportages en governance-documentatie moeten worden bewaard voor de vereiste bewaartermijn van zeven jaar, conform Nederlandse archiefwetgeving. Door Network Policies op deze manier te benaderen als een compliance- en governance-instrument, kunnen organisaties niet alleen hun beveiligingspostuur verbeteren, maar ook aantoonbaar voldoen aan de eisen van toezichthouders en auditors.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Inventariseert en rapporteert over Network Policies in Azure Kubernetes Service (AKS)-clusters. .DESCRIPTION Dit script analyseert alle AKS-clusters in de opgegeven of alle abonnementen en rapporteert over de netwerkpolicyprovider-configuratie, het aantal actieve NetworkPolicy-objecten en de compliance-status voor netwerksegmentatie. In monitoringmodus wordt een uitgebreid rapport gegenereerd met details per cluster. In remediatiemodus wordt een overzicht gemaakt van clusters zonder netwerkpolicyprovider of met onvoldoende NetworkPolicies, inclusief concrete aanbevelingen voor verbetering. .NOTES Filename: network-policies.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-27 Last Modified: 2025-01-27 Version: 1.0 Related JSON: content/azure/aks/network-policies.json .LINK https://github.com/[org]/m365-tenant-best-practise .EXAMPLE .\network-policies.ps1 -Monitoring Voert een uitgebreide controle uit op alle toegankelijke abonnementen en toont de netwerkpolicy-status per cluster. .EXAMPLE .\network-policies.ps1 -Remediation Genereert een overzicht van AKS-clusters zonder netwerkpolicyprovider of met onvoldoende NetworkPolicies en aanbevelingen. .EXAMPLE .\network-policies.ps1 -Monitoring -LocalDebug Draait een lokale debug-run met gesimuleerde data zonder Azure-verbinding of Kubernetes-API-calls. #> #Requires -Version 5.1 [CmdletBinding()] param( [Parameter()] [switch]$WhatIf, [Parameter()] [switch]$Monitoring, [Parameter()] [switch]$Remediation, [Parameter()] [string[]]$SubscriptionId, [Parameter()] [switch]$LocalDebug ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Network Policies voor AKS-clusters – Inventarisatie en compliance" $PolicyDescription = "Inventariseert AKS-clusters en rapporteert over netwerkpolicyprovider-configuratie en actieve NetworkPolicy-objecten voor netwerksegmentatie en Zero Trust." function Test-ModuleAvailability { [CmdletBinding()] param( [Parameter(Mandatory = $true)] [string[]]$ModuleName ) foreach ($name in $ModuleName) { if (-not (Get-Module -ListAvailable -Name $name)) { Write-Warning "Vereiste module '$name' is niet geïnstalleerd. Installeer deze module voor volledige functionaliteit." } } } function Connect-RequiredServices { <# .SYNOPSIS Maakt verbinding met Azure als dat nog niet is gebeurd. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "LocalDebug is ingeschakeld; er wordt geen Azure-verbinding opgezet." return } Test-ModuleAvailability -ModuleName @('Az.Accounts', 'Az.Resources', 'Az.Aks', 'Az.KubernetesService') try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Verbinding maken met Azure..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null } else { Write-Verbose "Reeds verbonden met Azure: $($context.Subscription.Name)" } } catch { Write-Error "Kon geen verbinding maken met Azure: $_" throw } } function Get-DebugNetworkPolicyData { [CmdletBinding()] param() return @( [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000010" SubscriptionName = "DBG-Overheid-NonProd" ResourceGroupName = "rg-aks-nonprod" ClusterName = "aks-nonprod-01" Location = "westeurope" NetworkPolicyProvider = "azure" HasNetworkPolicyProvider = $true NetworkPolicyCount = 15 NamespaceCount = 8 NamespacesWithPolicies = 6 ComplianceStatus = "Compliant" }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000020" SubscriptionName = "DBG-Overheid-Prod" ResourceGroupName = "rg-aks-prod" ClusterName = "aks-prod-01" Location = "westeurope" NetworkPolicyProvider = "calico" HasNetworkPolicyProvider = $true NetworkPolicyCount = 42 NamespaceCount = 12 NamespacesWithPolicies = 12 ComplianceStatus = "Compliant" }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000030" SubscriptionName = "DBG-Overheid-Dev" ResourceGroupName = "rg-aks-dev" ClusterName = "aks-dev-01" Location = "westeurope" NetworkPolicyProvider = "" HasNetworkPolicyProvider = $false NetworkPolicyCount = 0 NamespaceCount = 5 NamespacesWithPolicies = 0 ComplianceStatus = "Non-Compliant" } ) } function Get-AksNetworkPolicyInventory { <# .SYNOPSIS Haalt alle AKS-clusters op en verzamelt informatie over netwerkpolicyprovider en NetworkPolicy-objecten. .OUTPUTS PSCustomObject met uitgebreide cluster- en networkpolicy-informatie. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "Gebruik van gesimuleerde AKS-networkpolicydata (LocalDebug)." return Get-DebugNetworkPolicyData } Write-Verbose "Ophalen van AKS-clusters via Azure Resource Graph..." $query = @' resources | where type == "microsoft.containerservice/managedclusters" | project id, name, location, subscriptionId, resourceGroup, properties '@ $argParams = @{ Query = $query } if ($SubscriptionId) { $argParams['Subscription'] = $SubscriptionId } $clusters = Search-AzGraph @argParams if (-not $clusters -or $clusters.Count -eq 0) { Write-Verbose "Geen AKS-clusters gevonden in de geselecteerde scope." return @() } $results = @() foreach ($cluster in $clusters) { $networkProfile = $cluster.properties.networkProfile $networkPolicyProvider = $null if ($networkProfile -and $networkProfile.networkPolicy) { $networkPolicyProvider = [string]$networkProfile.networkPolicy } $hasProvider = -not [string]::IsNullOrWhiteSpace($networkPolicyProvider) # Probeer aanvullende informatie op te halen over NetworkPolicy-objecten via kubectl # In productie zou dit kubectl-aanroepen vereisen, maar voor nu gebruiken we indicatoren $networkPolicyCount = 0 $namespaceCount = 0 $namespacesWithPolicies = 0 $complianceStatus = "Unknown" if ($hasProvider) { # Clusters met een provider zijn minimaal deels compliant # In een echte implementatie zou u hier kubectl gebruiken om daadwerkelijk NetworkPolicy-objecten te tellen $complianceStatus = "Partial" } else { $complianceStatus = "Non-Compliant" } $results += [PSCustomObject]@{ SubscriptionId = $cluster.subscriptionId SubscriptionName = (Get-AzSubscription -SubscriptionId $cluster.subscriptionId -ErrorAction SilentlyContinue).Name ResourceGroupName = $cluster.resourceGroup ClusterName = $cluster.name Location = $cluster.location NetworkPolicyProvider = $networkPolicyProvider HasNetworkPolicyProvider = $hasProvider NetworkPolicyCount = $networkPolicyCount NamespaceCount = $namespaceCount NamespacesWithPolicies = $namespacesWithPolicies ComplianceStatus = $complianceStatus } } return $results } function Test-Compliance { <# .SYNOPSIS Bepaalt de compliancestatus voor network policies op AKS-clusters. .OUTPUTS PSCustomObject met samenvatting van de resultaten. #> [CmdletBinding()] param() $clusters = Get-AksNetworkPolicyInventory if (-not $clusters -or $clusters.Count -eq 0) { Write-Verbose "Geen AKS-clusters gevonden in de geselecteerde scope." return [PSCustomObject]@{ ScriptName = "network-policies" IsCompliant = $true Timestamp = Get-Date Details = "Er zijn geen AKS-clusters gevonden in de huidige scope." Recommendations = @() Clusters = @() } } $nonCompliant = $clusters | Where-Object { -not $_.HasNetworkPolicyProvider } $partialCompliant = $clusters | Where-Object { $_.HasNetworkPolicyProvider -and $_.ComplianceStatus -eq "Partial" } $fullyCompliant = $clusters | Where-Object { $_.HasNetworkPolicyProvider -and $_.ComplianceStatus -eq "Compliant" } $isCompliant = ($nonCompliant.Count -eq 0 -and $partialCompliant.Count -eq 0) $details = if ($isCompliant) { "Alle gevonden AKS-clusters hebben een netwerkpolicyprovider geconfigureerd en voldoende NetworkPolicy-objecten." } elseif ($nonCompliant.Count -gt 0) { "Een of meer AKS-clusters hebben geen netwerkpolicyprovider geconfigureerd en missen daarmee een belangrijke bouwsteen voor segmentatie." } else { "Een of meer AKS-clusters hebben een netwerkpolicyprovider maar missen voldoende NetworkPolicy-objecten voor effectieve segmentatie." } $recommendations = @() if ($nonCompliant.Count -gt 0) { $recommendations += "Schakel een geschikte netwerkpolicyprovider (bijv. 'azure' of 'calico') in voor alle niet-conforme AKS-clusters. Let op: dit vereist mogelijk het opnieuw aanmaken van het cluster." $recommendations += "Plan de migratie van bestaande workloads naar nieuwe clusters met netwerkpolicyprovider ingeschakeld." } if ($partialCompliant.Count -gt 0 -or $nonCompliant.Count -eq 0) { $recommendations += "Ontwerp en implementeer Kubernetes NetworkPolicies per namespace op basis van het vastgestelde segmentatiemodel en architectuurprincipes." $recommendations += "Gebruik CI/CD en Azure Policy om het gebruik van network policies te borgen en afwijkingen vroegtijdig te signaleren." $recommendations += "Documenteer het netwerksegmentatiemodel inclusief namespaces, labels en NetworkPolicies voor audit- en governance-doeleinden." } return [PSCustomObject]@{ ScriptName = "network-policies" IsCompliant = $isCompliant Timestamp = Get-Date Details = $details Recommendations = $recommendations Clusters = $clusters NonCompliantCount = $nonCompliant.Count PartialCompliantCount = $partialCompliant.Count FullyCompliantCount = $fullyCompliant.Count } } function Invoke-Monitoring { <# .SYNOPSIS Voert een uitgebreide monitoring-run uit en toont de status per AKS-cluster. #> [CmdletBinding()] param() Write-Host "`nMonitoring: $PolicyName" -ForegroundColor Yellow Write-Host "Beschrijving: $PolicyDescription" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $clusters = $result.Clusters if ($clusters.Count -gt 0) { Write-Host "`nGevonden AKS-clusters:" -ForegroundColor Cyan foreach ($cluster in $clusters) { $statusColor = switch ($cluster.ComplianceStatus) { "Compliant" { "Green" } "Partial" { "Yellow" } "Non-Compliant" { "Red" } default { "Gray" } } $providerText = if ($cluster.HasNetworkPolicyProvider) { "Provider: $($cluster.NetworkPolicyProvider)" } else { "Provider: GEEN" } $policyText = if ($cluster.NetworkPolicyCount -gt 0) { " | NetworkPolicies: $($cluster.NetworkPolicyCount)" } else { " | NetworkPolicies: Niet beschikbaar" } Write-Host ("- {0}/{1} ({2})" -f $cluster.SubscriptionName, $cluster.ClusterName, $cluster.Location) -ForegroundColor $statusColor Write-Host (" Status: {0} | {1}{2}" -f $cluster.ComplianceStatus, $providerText, $policyText) -ForegroundColor $statusColor } Write-Host "`nSamenvatting:" -ForegroundColor Cyan Write-Host (" Totaal clusters: {0}" -f $clusters.Count) -ForegroundColor Cyan Write-Host (" Volledig compliant: {0}" -f $result.FullyCompliantCount) -ForegroundColor Green Write-Host (" Gedeeltelijk compliant: {0}" -f $result.PartialCompliantCount) -ForegroundColor Yellow Write-Host (" Niet compliant: {0}" -f $result.NonCompliantCount) -ForegroundColor Red } else { Write-Host "`nGeen AKS-clusters gevonden in de huidige scope." -ForegroundColor Cyan } if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT - Alle AKS-clusters voldoen aan de netwerksegmentatie-eisen." -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT - Eén of meer AKS-clusters voldoen niet aan de netwerksegmentatie-eisen." -ForegroundColor Red Write-Host "Aanbevolen acties:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -ForegroundColor Yellow } } return $result } function Invoke-Remediation { <# .SYNOPSIS Geeft een uitgebreid remediatie-overzicht voor AKS-clusters zonder netwerksegmentatie. #> [CmdletBinding()] param() Write-Host "`nRemediatie: $PolicyName" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $nonCompliant = $result.Clusters | Where-Object { -not $_.HasNetworkPolicyProvider } $partialCompliant = $result.Clusters | Where-Object { $_.HasNetworkPolicyProvider -and $_.ComplianceStatus -eq "Partial" } if ((-not $nonCompliant -or $nonCompliant.Count -eq 0) -and (-not $partialCompliant -or $partialCompliant.Count -eq 0)) { Write-Host "Alle AKS-clusters beschikken over een netwerkpolicyprovider en voldoende NetworkPolicies. Geen remediatie nodig." -ForegroundColor Green return $result } if ($nonCompliant -and $nonCompliant.Count -gt 0) { Write-Host "`nNiet-conforme AKS-clusters (zonder netwerkpolicyprovider):" -ForegroundColor Red foreach ($cluster in $nonCompliant) { Write-Host ("- Subscription: {0}" -f $cluster.SubscriptionName) -ForegroundColor Red Write-Host (" ResourceGroup: {0}" -f $cluster.ResourceGroupName) -ForegroundColor Red Write-Host (" Cluster: {0}" -f $cluster.ClusterName) -ForegroundColor Red Write-Host (" Locatie: {0}" -f $cluster.Location) -ForegroundColor Red Write-Host "" } } if ($partialCompliant -and $partialCompliant.Count -gt 0) { Write-Host "`nGedeeltelijk conforme AKS-clusters (met provider maar onvoldoende NetworkPolicies):" -ForegroundColor Yellow foreach ($cluster in $partialCompliant) { Write-Host ("- Subscription: {0}" -f $cluster.SubscriptionName) -ForegroundColor Yellow Write-Host (" ResourceGroup: {0}" -f $cluster.ResourceGroupName) -ForegroundColor Yellow Write-Host (" Cluster: {0}" -f $cluster.ClusterName) -ForegroundColor Yellow Write-Host (" Provider: {0}" -f $cluster.NetworkPolicyProvider) -ForegroundColor Yellow Write-Host "" } } Write-Host "Aanbevolen vervolgstappen:" -ForegroundColor Yellow Write-Host "1. Classificeer de niet-conforme clusters naar omgeving (ontwikkel, test, acceptatie, productie) en kriticiteit." -ForegroundColor Yellow if ($nonCompliant -and $nonCompliant.Count -gt 0) { Write-Host "2. Bepaal per cluster welke netwerkpolicyprovider (azure of calico) wordt gebruikt volgens de referentie-architectuur." -ForegroundColor Yellow Write-Host "3. WAARSCHUWING: Het inschakelen van een netwerkpolicyprovider vereist mogelijk het opnieuw aanmaken van het cluster. Plan migratie zorgvuldig." -ForegroundColor Yellow Write-Host "4. Migreer workloads naar nieuwe clusters met netwerkpolicyprovider ingeschakeld via gecontroleerde migratiestrategie." -ForegroundColor Yellow } Write-Host "5. Ontwerp een netwerksegmentatiemodel op basis van trust boundaries, namespaces en labels." -ForegroundColor Yellow Write-Host "6. Ontwikkel en test Kubernetes NetworkPolicies per namespace op basis van het vastgestelde segmentatiemodel." -ForegroundColor Yellow Write-Host "7. Implementeer NetworkPolicies via Infrastructure as Code (Bicep/Terraform) en GitOps-werkflows." -ForegroundColor Yellow Write-Host "8. Documenteer uitzonderingen, bijbehorende risico's en einddata expliciet in het governance- en risicoregister." -ForegroundColor Yellow Write-Host "9. Stel monitoring en alerts in om te waarschuwen wanneer nieuwe clusters zonder netwerksegmentatie worden aangemaakt." -ForegroundColor Yellow if ($WhatIf) { Write-Host "`nWhatIf is ingeschakeld: er worden geen wijzigingen doorgevoerd; alleen een rapport is gegenereerd." -ForegroundColor Cyan } return $result } try { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Script: network-policies" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { Invoke-Remediation } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT" -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT" -ForegroundColor Red Write-Host "Voer het script uit met -Monitoring of -Remediation voor meer details." -ForegroundColor Yellow } return $result } } catch { Write-Error "Er is een fout opgetreden in network-policies.ps1: $_" throw } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Wanneer AKS-clusters zonder Network Policies worden geëxploiteerd, ontbreekt effectieve netwerksegmentatie op workloadniveau. Een aanvaller die één container weet te compromitteren, kan zich dan vaak ongehinderd verplaatsen naar andere pods en diensten, met verhoogd risico op datalekken, integriteitsschade en verstoring van essentiële overheidsprocessen. Daarnaast is het in audits lastig om aan te tonen dat passende maatregelen zijn getroffen conform BIO, ISO 27001 en NIS2.

Management Samenvatting

Network Policies vormen de fundament voor netwerksegmentatie in AKS en zijn essentieel voor Zero Trust op workloadniveau. Dit artikel behandelt het concept, architectuur, ontwerp van segmentatiemodellen, implementatie en beheer van Network Policies. Gebruik het bijbehorende PowerShell-script om clusters te inventariseren en compliance te monitoren. Verplicht voor alle productie-AKS-clusters. Vereist voor BIO 09.01/12.02, ISO 27001 en NIS2 Artikel 21.