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

Beveiliging Van Azure Kubernetes Service (AKS) Voor De Publieke Sector

📅 2025-11-26
•
⏱️ 20 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Azure Kubernetes Service (AKS) is voor veel Nederlandse overheidsorganisaties de standaardplatformdienst voor het hosten van containerworkloads en moderne applicaties. Juist omdat AKS vaak bedrijfskritische en publiek gerichte diensten draagt, moet de beveiliging vanaf ontwerp tot en met beheer aantoonbaar op orde zijn.

Aanbeveling
IMPLEMENT
Risico zonder
High
Risk Score
8/10
Implementatie
100u (tech: 60u)
Van toepassing op:
✓ Azure Tenant
✓ Azure Kubernetes Service (AKS)

Kubernetes-clusters zijn complex: er zijn meerdere lagen (control plane, nodes, netwerk, identiteiten, containers, images en CI/CD-ketens) die elkaar beïnvloeden. In de praktijk ontstaan snel onbedoeld openstaande API’s, te ruime rechten voor workloads, onvoldoende gesegmenteerde netwerken of kwetsbare containerimages. Voor Nederlandse overheidsorganisaties komt daar bovenop dat BIO, NIS2 en sectorale normenkaders eisen stellen aan toegangsbeveiliging, logging, configuratiebeheer en continuïteit. Een verkeerd geconfigureerd AKS-cluster kan leiden tot datalekken, misbruik van rekenkracht, verstoring van kritieke diensten of het onopgemerkt uitvoeren van malware. Zonder duidelijke richtlijnen en controles is het voor CISO’s, architecten en beheerteams lastig om aan bestuurders en toezichthouders uit te leggen of AKS-omgevingen daadwerkelijk veilig zijn ingericht.

PowerShell Modules Vereist
Primary API: Azure Portal, Azure Resource Manager
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Aks

Implementatie

Dit index-artikel beschrijft hoe u AKS inricht en beheert binnen de "Nederlandse Baseline voor Veilige Cloud". We behandelen de rol van AKS binnen de cloudarchitectuur, de belangrijkste beveiligingsprincipes voor cluster- en workloadconfiguratie, en hoe u governance, monitoring en remediatie organiseert. Daarnaast laten we zien hoe u met een PowerShell-script een eerste overzicht krijgt van de beveiligingsstatus van uw clusters, zodat u gericht vervolgartikelen en detailcontroles kunt inzetten.

Rol van AKS in de overheidsarchitectuur

AKS is in essentie geen doel op zich, maar een generiek platform waarop uiteenlopende applicaties en microservices worden gehost. Voor Nederlandse overheidsorganisaties varieert dit van burgerportalen en API-lagen tot interne integratiecomponenten en data-analyseservices. Het cluster vormt daarmee een gedeelde infrastructuurlaag waarop meerdere teams en domeinen hun workloads uitrollen. Zonder heldere architectuurprincipes kan dit al snel leiden tot een verzameling van los geconfigureerde namespaces, uiteenlopende security-standaarden en onduidelijke verantwoordelijkheden rond beheer en incidentrespons. Daarom moet AKS vanaf de start worden gepositioneerd als een centraal platform met expliciete kaders voor wie er gebruik van mag maken, onder welke voorwaarden en met welke mate van isolatie tussen workloads.

In een volwassen cloudarchitectuur is AKS ingebed in een Zero Trust-model. Dat betekent onder meer dat toegang tot de Kubernetes API uitsluitend via geauthenticeerde en geautoriseerde identiteiten verloopt, bij voorkeur geïntegreerd met Entra ID (Azure AD) en rolgebaseerde toegang (RBAC). Beheerconnectiviteit via het internet wordt beperkt of volledig afgesloten, waarbij beheer uitsluitend plaatsvindt via beveiligde beheersegmenten of private endpoints. Worker nodes draaien bij voorkeur in een dedicated subnet met Network Security Groups en, waar mogelijk, gebruik van Azure CNI en netwerkpolicy’s die verkeer tussen pods en namespaces beperken. Door deze netwerk- en identiteitsarchitectuur strak te definiëren, wordt voorkomen dat individuele teams eigen, mogelijk onveilige, wegen zoeken om toegang te krijgen tot het cluster.

Een ander architectuurprincipe is de scheiding tussen omgevingen: ontwikkel-, test-, acceptatie- en productieclusters worden logisch én technisch gescheiden, bijvoorbeeld via verschillende Azure-subscripties en managementgroepen. Productieclusters volgen strengere policies voor zaken als node hardening, toegangsbeheer en change management dan niet-productieomgevingen. Bovendien worden AKS-clusters niet geïsoleerd ontworpen, maar in samenhang met andere beveiligingscomponenten zoals Azure Key Vault voor geheimenbeheer, Azure Monitor en Log Analytics voor logging, Defender for Cloud voor dreigingsdetectie en Azure Policy voor configuratiehandhaving. Deze samenhang moet zichtbaar zijn in architectuurdocumenten en besluitvorming, zodat auditors en toezichthouders kunnen herleiden hoe AKS zich verhoudt tot het bredere beveiligingslandschap.

Beveiligingsbaseline voor AKS-clusters en workloads

Een robuuste beveiligingsbaseline voor AKS begint bij het cluster zelf. Belangrijke uitgangspunten zijn het inschakelen van RBAC, het uitschakelen van lokale beheeraccounts waar mogelijk, het toepassen van private clusters zodat de Kubernetes API niet publiek bereikbaar is, en het afdwingen van versleuteling van data in rust en tijdens transport. Daarnaast dienen node pools te worden geconfigureerd met up-to-date images, automatische patching en – waar mogelijk – gebruik van node verharding volgens de door Microsoft en het NCSC aanbevolen richtlijnen. Voor control plane en node logs moet diagnostische logging worden geactiveerd en doorgestuurd naar een centrale Log Analytics-werkruimte of SIEM, zodat verdachte patronen tijdig worden gedetecteerd.

Op workloadniveau ligt de focus op het minimaliseren van privileges en het afdwingen van veilige configuraties via policies. Containers draaien idealiter niet als root, deployments maken geen gebruik van onbeschermde hostPath-mounts en secrets worden niet hardcoded in images of configuratiebestanden, maar via Key Vault of Kubernetes Secrets met passende toegangsrestricties. Resourcequota en limieten voorkomen dat individuele workloads onevenredig veel CPU of geheugen verbruiken, wat de beschikbaarheid van andere diensten in gevaar kan brengen. Beveiligingsscanners voor containerimages – bijvoorbeeld geïntegreerd in Defender for Cloud of de gebruikte container registry – worden ingezet om bekende kwetsbaarheden in images vroegtijdig te signaleren. Door deze maatregelen te combineren ontstaat een defense-in-depth-benadering waarin fouten in één laag niet direct leiden tot een volledig compromis van het cluster.

Azure Policy speelt een sleutelrol in het afdwingen van de beveiligingsbaseline. Met beleidssets kunnen organisaties afdwingen dat nieuwe clusters en namespaces voldoen aan minimumeisen, zoals het inschakelen van Defender for Cloud aanbevelingen, het verplicht gebruiken van beheerde identiteiten voor workloads en het blokkeren van ongewenste configuraties (bijvoorbeeld het toestaan van privileged containers). Deze policies worden centraal beheerd op managementgroep- of abonnementsniveau en zijn gekoppeld aan specifieke compliancedomeinen, zoals de CIS Kubernetes Benchmark of interne richtlijnen van de organisatie. Rapportages uit Azure Policy en Defender for Cloud geven vervolgens inzicht in de feitelijke naleving, wat essentieel is voor sturing door CISO’s en voor externe audits.

Monitoring en rapportage van AKS-beveiliging

Gebruik PowerShell-script index.ps1 (functie Invoke-Monitoring) – Geeft een compact overzicht van AKS-clusters in de tenant en hun belangrijkste beveiligingskenmerken, zoals RBAC en netwerkpolicy’s..

Monitoring van AKS-beveiliging is meer dan het inrichten van enkele dashboards. Organisaties moeten structureel zicht hebben op waar clusters draaien, welke configuraties zijn gekozen en of kritieke beveiligingsinstellingen daadwerkelijk zijn ingeschakeld. Dit omvat onder andere het monitoren van het aantal clusters per omgeving, het gebruik van RBAC en geïntegreerde identiteiten, de status van Defender for Cloud aanbevelingen, het gebruik van netwerkpolicy’s en het aan- of afwezig zijn van publieke endpoints. Door deze informatie te centraliseren in een overzicht, kunnen CISO’s en platformteams gericht prioriteiten stellen: eerst de clusters zonder basismaatregelen, daarna clusters met specifieke kwetsbaarheden of afwijkingen ten opzichte van de standaard.

Het bij dit artikel horende PowerShell-script is bewust lichtgewicht gehouden en richt zich op een eerste inventarisatie. Het script leest alle AKS-clusters in de tenant uit en rapporteert per cluster onder meer de resourcegroep, locatie, of RBAC is ingeschakeld en welke netwerkpolicy is geconfigureerd. De uitvoer kan worden gebruikt als input voor meer gedetailleerde analyses, bijvoorbeeld door resultaten te exporteren naar CSV of in te lezen in een dashboardingoplossing. Belangrijk is dat dit script niet in plaats komt van diepgaande beveiligingsscans of gespecialiseerde tooling, maar fungeert als startpunt waarmee u snel ziet waar de grootste afwijkingen zitten en welke clusters aanvullende aandacht nodig hebben.

Remediatie en structurele verbetering

Gebruik PowerShell-script index.ps1 (functie Invoke-Remediation) – Ondersteunt het structureren van verbeteracties op basis van de inventarisatie van AKS-clusters en hun beveiligingsstatus..

Wanneer blijkt dat AKS-clusters niet voldoen aan de gewenste beveiligingsbaseline, is een gestructureerde remediatieaanpak nodig. Ad-hoc wijzigingen – bijvoorbeeld het handmatig aanpassen van een enkele clusterconfiguratie – lossen doorgaans slechts symptomen op en vergroten de kans op inconsistenties tussen omgevingen. In plaats daarvan moeten verbetermaatregelen worden vastgelegd in een programma waarin per cluster en per beveiligingsdomein wordt beschreven welke aanpassing nodig is, wie eigenaar is, welke risico’s daarmee worden verkleind en hoe de wijziging wordt getest en uitgerold. Dit programma sluit idealiter aan op bestaande change-, release- en CAB-processen, zodat beveiligingsverbeteringen niet losstaan van de reguliere lifecycle van de omgeving.

Het script bij dit artikel automatiseert de eerste stap van remediatie: het overzichtelijk maken van de huidige situatie. Door de scriptuitvoer te combineren met interne richtlijnen en referentieconfiguraties, kunnen platformteams snel zien welke clusters als eerste aandacht vragen. De resultaten worden vertaald naar concrete acties, zoals het inschakelen van RBAC, het omschakelen naar private clusters, het activeren van netwerkpolicy’s of het herzien van rollen en toegangsmodellen voor beheeraccounts. Waar mogelijk worden deze maatregelen opgenomen in Infrastructure as Code-templates en Azure Policy-definities, zodat nieuwe clusters automatisch volgens dezelfde standaard worden uitgerold. Zo wordt remediatie niet alleen een eenmalige opschoningsactie, maar onderdeel van een continue verbetercyclus.

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 Overzichtsmonitoring en remediatie-ondersteuning voor AKS-beveiliging. .DESCRIPTION Geeft een samenvattend beeld van Azure Kubernetes Service (AKS)-clusters in de tenant en hun belangrijkste beveiligingskenmerken (zoals RBAC en netwerkpolicy). Het script is bedoeld als lichtgewicht control binnen de "Nederlandse Baseline voor Veilige Cloud". .NOTES Filename: index.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Last Modified: 2025-11-26 Version: 1.0 Related JSON: content/azure/aks-security/index.json .EXAMPLE .\index.ps1 -Monitoring -LocalDebug Toont een voorbeeldoverzicht zonder verbinding te maken met Azure (voor lokale tests). .EXAMPLE .\index.ps1 -Monitoring Voert een lichte monitoring uit op AKS-clusters in de huidige context. .EXAMPLE .\index.ps1 -Remediation -LocalDebug Toont welke type verbeteracties kunnen worden gepland op basis van een inventarisatie. #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Aks [CmdletBinding()] param( [Parameter(HelpMessage = "Voer een samenvattende monitoring uit van AKS-clusters.")] [switch]$Monitoring, [Parameter(HelpMessage = "Ondersteun het opstellen van remediatie- en verbeteracties.")] [switch]$Remediation, [Parameter(HelpMessage = "Voer geen live Azure-calls uit maar gebruik voorbeelddata (voor lokale debug).")] [switch]$LocalDebug, [Parameter(HelpMessage = "Toon welke acties zouden worden uitgevoerd zonder daadwerkelijk te wijzigen.")] [switch]$WhatIf ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' function Get-AksSecurityInventory { <# .SYNOPSIS Haalt een overzicht op van AKS-clusters en enkele beveiligingskenmerken. .OUTPUTS PSCustomObject met clusterinformatie. #> [CmdletBinding()] param( [switch]$UseDebugData ) if ($UseDebugData) { Write-Verbose "Gebruik van lokale debugdata; er wordt geen verbinding met Azure gemaakt." $sample = @( [pscustomobject]@{ Name = "aks-demo-cluster" ResourceGroup = "rg-demo" Location = "westeurope" RbacEnabled = $true NetworkPolicy = "azure" }, [pscustomobject]@{ Name = "aks-legacy-cluster" ResourceGroup = "rg-legacy" Location = "westeurope" RbacEnabled = $false NetworkPolicy = "none" } ) return [pscustomobject]@{ Clusters = $sample TotalClusters = $sample.Count } } if (-not (Get-AzContext -ErrorAction SilentlyContinue)) { Write-Verbose "Geen actieve Az-context gevonden; probeer Connect-AzAccount uit te voeren." Connect-AzAccount -ErrorAction Stop | Out-Null } $aks = Get-AzAks -ErrorAction SilentlyContinue if (-not $aks) { return [pscustomobject]@{ Clusters = @() TotalClusters = 0 } } $list = foreach ($cluster in $aks) { [pscustomobject]@{ Name = $cluster.Name ResourceGroup = $cluster.ResourceGroupName Location = $cluster.Location RbacEnabled = [bool]$cluster.EnableRBAC NetworkPolicy = $cluster.NetworkProfile.NetworkPolicy } } return [pscustomobject]@{ Clusters = $list TotalClusters = $list.Count } } function Invoke-Monitoring { <# .SYNOPSIS Voert een samenvattende monitoring uit van AKS-clusters. #> [CmdletBinding()] param() Write-Host "`nMonitoring: AKS-beveiligingsoverzicht" -ForegroundColor Yellow Write-Host "======================================" -ForegroundColor Yellow $inventory = Get-AksSecurityInventory -UseDebugData:$LocalDebug Write-Host ("Totaal aantal AKS-clusters: {0}" -f $inventory.TotalClusters) -ForegroundColor Cyan if ($inventory.TotalClusters -eq 0) { Write-Host "Er zijn geen AKS-clusters gevonden in de huidige context." -ForegroundColor Yellow return } foreach ($c in $inventory.Clusters) { $rbac = if ($c.RbacEnabled) { "RBAC: ingeschakeld" } else { "RBAC: UIT" } $netpol = if ([string]::IsNullOrWhiteSpace($c.NetworkPolicy)) { "NetworkPolicy: (geen)" } else { "NetworkPolicy: $($c.NetworkPolicy)" } Write-Host "" Write-Host ("Cluster: {0}" -f $c.Name) -ForegroundColor White Write-Host (" Resourcegroep : {0}" -f $c.ResourceGroup) -ForegroundColor Gray Write-Host (" Locatie : {0}" -f $c.Location) -ForegroundColor Gray Write-Host (" {0}" -f $rbac) -ForegroundColor Gray Write-Host (" {0}" -f $netpol) -ForegroundColor Gray } $clustersWithoutRbac = $inventory.Clusters | Where-Object { -not $_.RbacEnabled } $clustersWithoutNetPol = $inventory.Clusters | Where-Object { -not $_.NetworkPolicy -or $_.NetworkPolicy -eq "none" } if ($clustersWithoutRbac.Count -gt 0 -or $clustersWithoutNetPol.Count -gt 0) { Write-Host "`nSamenvatting mogelijke risico's:" -ForegroundColor Yellow if ($clustersWithoutRbac.Count -gt 0) { Write-Host " - Clusters zonder RBAC ingeschakeld:" -ForegroundColor Yellow $clustersWithoutRbac | ForEach-Object { Write-Host (" * {0}" -f $_.Name) -ForegroundColor Yellow } } if ($clustersWithoutNetPol.Count -gt 0) { Write-Host " - Clusters zonder netwerkpolicy (of 'none'):" -ForegroundColor Yellow $clustersWithoutNetPol | ForEach-Object { Write-Host (" * {0}" -f $_.Name) -ForegroundColor Yellow } } } else { Write-Host "`nAlle gevonden clusters hebben RBAC ingeschakeld en een netwerkpolicy geconfigureerd." -ForegroundColor Green } } function Invoke-Remediation { <# .SYNOPSIS Ondersteunt het structureren van remediatieacties voor AKS-beveiliging. .DESCRIPTION Dit script voert geen automatische configuratiewijzigingen uit, maar helpt om de output van de monitoring te vertalen naar concrete verbeteracties. #> [CmdletBinding()] param() Write-Host "`nRemediatie-ondersteuning: AKS-beveiliging" -ForegroundColor Yellow Write-Host "==========================================" -ForegroundColor Yellow $inventory = Get-AksSecurityInventory -UseDebugData:$LocalDebug if ($inventory.TotalClusters -eq 0) { Write-Host "Geen AKS-clusters gevonden. Controleer of de juiste subscription/context is geselecteerd." -ForegroundColor Yellow return } $clustersWithoutRbac = $inventory.Clusters | Where-Object { -not $_.RbacEnabled } $clustersWithoutNetPol = $inventory.Clusters | Where-Object { -not $_.NetworkPolicy -or $_.NetworkPolicy -eq "none" } if ($clustersWithoutRbac.Count -eq 0 -and $clustersWithoutNetPol.Count -eq 0) { Write-Host "Op basis van de gecontroleerde kenmerken zijn geen directe remediatiepunten gevonden." -ForegroundColor Green Write-Host "Gebruik aanvullende detailcontroles om configuraties verder te toetsen." -ForegroundColor Green return } if ($clustersWithoutRbac.Count -gt 0) { Write-Host "`nAanbevolen acties voor clusters zonder RBAC:" -ForegroundColor Yellow foreach ($c in $clustersWithoutRbac) { Write-Host (" * Cluster '{0}' in resourcegroep '{1}': beoordeel de impact van het inschakelen van RBAC, plan wijziging via changeproces en test in niet-productie." -f $c.Name, $c.ResourceGroup) -ForegroundColor White } } if ($clustersWithoutNetPol.Count -gt 0) { Write-Host "`nAanbevolen acties voor clusters zonder netwerkpolicy:" -ForegroundColor Yellow foreach ($c in $clustersWithoutNetPol) { Write-Host (" * Cluster '{0}' in resourcegroep '{1}': definieer gewenste netwerksegmentatie (bijvoorbeeld via Azure CNI + network policy), test policies in een aparte omgeving en rol gefaseerd uit." -f $c.Name, $c.ResourceGroup) -ForegroundColor White } } if ($WhatIf) { Write-Host "`n[WhatIf] Er zijn geen wijzigingen doorgevoerd; gebruik deze output om een remediatieplan op te stellen." -ForegroundColor Yellow } else { Write-Host "`nGebruik deze aanbevelingen om concrete tickets of werkpakketten te definiëren binnen het reguliere verbeterprogramma." -ForegroundColor Cyan } }

Risico zonder implementatie

Risico zonder implementatie
High: Wanneer AKS-clusters zonder duidelijke beveiligingsbaseline en toezicht worden uitgebaat, neemt de kans op succesvolle aanvallen, datalekken en verstoringen van kritieke diensten sterk toe. Dit ondermijnt het vertrouwen van burgers en bestuurders en kan leiden tot negatieve auditbevindingen en sancties vanuit toezichthouders.

Management Samenvatting

AKS biedt een krachtig platform voor moderne applicaties, maar vraagt om strikte beveiliging, governance en monitoring. Door een duidelijke architectuurrol te definiëren, een beveiligingsbaseline af te dwingen, clusters structureel te monitoren en remediatie in een continu verbeterprogramma onder te brengen, kunnen Nederlandse overheidsorganisaties AKS veilig en aantoonbaar compliant inzetten.