Kort: On-premise Kubernetes-clusters op basis van K3s, RKE2 of OpenShift geven gereguleerde organisaties volledige controle over data, toegang en compliance, zonder de jurisdictierisico's van Azure AKS, AWS EKS of Google GKE. Supply chain-veiligheid, secrets management en NIS-2-documentatie zijn daarbij niet optioneel maar structureel onderdeel van het platform.

Een on-premise Kubernetes soevereine containerinfrastructuur is een zelf beheerd cluster van containerorkestratiesoftware dat volledig binnen de juridische en fysieke controlesfeer van de eigen organisatie valt, zonder afhankelijkheid van een buitenlandse cloudprovider voor het beheervlak, de opslag of de toegangscontrole. Voor overheidsinstanties, advocatenkantoren, zorginstellingen en andere gereguleerde organisaties is dit onderscheid niet louter technisch, maar ook juridisch bepalend.

Waarom hyperscaler Kubernetes een soevereiniteitsrisico is

Managed Kubernetes-diensten zoals Azure AKS, AWS EKS en Google GKE nemen het beheer van het control plane uit handen, maar plaatsen dat control plane buiten uw juridische controle. Dat is de kern van het probleem.

Het control plane van een Kubernetes-cluster bevat de API-server, etcd (de configuratiedatabase), de scheduler en de controller manager. Bij hyperscaler-managed diensten draait dit control plane op infrastructuur die valt onder de rechtsmacht van de Verenigde Staten. De Amerikaanse CLOUD Act (2018) en de bredere reikwijdte van de Patriot Act geven Amerikaanse autoriteiten de bevoegdheid om bij Amerikaanse technologiebedrijven toegang te vorderen tot gegevens, ook wanneer die fysiek in Europa zijn opgeslagen. Dit geldt dus ook voor metadata, logbestanden en configuratiedata in het control plane.

Let op: Zelfs wanneer u uw workloads in een Europese AWS- of Azure-regio draait, valt het managed control plane juridisch onder Amerikaanse wetgeving. De locatie van de datacenterservers is niet gelijk aan de locatie van juridische zeggenschap.

Wojciech Wiewiórowski, Europese Toezichthouder voor Gegevensbescherming (EDPS), stelde het treffend: “Sovereignty is not just about where data is stored, it is about who has the legal authority to access it and under what conditions.” Die juridische autoriteit ontbreekt bij hyperscaler PaaS-diensten zodra een buitenlandse wet van toepassing is op de aanbieder.

Daarnaast binden hyperscaler-specifieke PaaS-diensten uw architectuur aan propriëtaire API’s en toolchains. Wie Kubernetes-workloads bouwt op AKS-specifieke integraties (zoals Azure AD Workload Identity of AWS IAM Roles for Service Accounts in EKS-specifieke vorm), creëert vendor lock-in die migratie kostbaar maakt.

Open-source Kubernetes-distributies vergeleken

Voor soevereine omgevingen zijn er meerdere volwaardige open-source Kubernetes-distributies beschikbaar die u volledig zelf beheert.

Distributie Beheerder Geschikt voor Beveiligingsprofiel Minimale resources
K3s Rancher by SUSE Kleine tot middelgrote organisaties, edge-omgevingen Ingebouwde TLS, RBAC, Secrets Encryption; lage aanvalsoppervlak door minimale footprint 512 MB RAM per node
RKE2 Rancher by SUSE Gereguleerde sectoren, FIPS 140-2-vereisten FIPS-compliant cryptografie, CIS Benchmark hardening out-of-the-box 2 GB RAM per node
Red Hat OpenShift Red Hat (IBM) Grote overheidsorganisaties, enterprise-compliance Geïntegreerde SCCs, OPA/Gatekeeper, ingebouwde image scanning, FIPS-ondersteuning 16 GB RAM per control plane node

RKE2 (Rancher by SUSE) is specifiek ontworpen voor omgevingen die moeten voldoen aan strenge overheidsnormen. De distributie volgt standaard de CIS Kubernetes Benchmark en ondersteunt FIPS 140-2-gecertificeerde cryptografische modules, wat relevant is voor organisaties die werken met gerubriceerde informatie of onder nationale beveiligingskaders vallen.

Red Hat OpenShift biedt de meest volledige geïntegreerde beveiligingsstack, maar vereist aanzienlijk meer hardware en beheerexpertise. Voor middelgrote overheidsorganisaties is K3s of RKE2 in veel gevallen een proportionelere keuze.

Supply chain-veiligheid, containerregistries en de SBOM-verplichting

Een soevereine Kubernetes-omgeving is alleen zo veilig als de containerimages die erin draaien. Supply chain-aanvallen, waarbij kwaadaardige code in een upstream-image wordt geïnjecteerd, vormen een reëel risico.

De oplossing bestaat uit drie lagen. Ten eerste: host uw eigen containerregistry. Harbor is een open-source, OCI-conforme (Open Container Initiative) registry die volledig on-premise of in een Europese co-locatiefaciliteit kan worden gehost. Harbor biedt geïntegreerde vulnerability scanning, role-based access control en ondersteuning voor image-signatuurverificatie via Notary v2. Dit maakt Harbor een soevereine vervanger voor Docker Hub, Amazon ECR of Azure Container Registry.

Ten tweede: verifieer de herkomst van elke image via cryptografische signaturen. Gebruik tooling zoals Cosign (onderdeel van het Sigstore-project) om images te ondertekenen en die handtekeningen te verifiëren voordat Kubernetes een container mag starten. Koppel dit aan een admission controller die unsigned of onbekende images blokkeert.

Ten derde: stel een Software Bill of Materials (SBOM) op voor elke containerimage. De Cyber Resilience Act, die in 2024 in werking trad, verplicht in artikel 13 fabrikanten van producten met digitale elementen om een SBOM op te stellen en gedurende de levensduur van het product beschikbaar te houden. Voor organisaties die zelf software verpakken in containers, geldt deze verplichting ook voor intern ontwikkelde en intern gebruikte images wanneer deze als product worden aangemerkt. Tools zoals Syft of Trivy kunnen automatisch SBOM-bestanden genereren in standaardformaten zoals SPDX of CycloneDX.

NIST SP 800-190 (Application Container Security Guide) biedt een gedetailleerd referentiekader voor het beveiligen van containerimages, registries, orkestratieplatformen en de onderliggende host-OS. Dit document is een praktisch startpunt voor het opstellen van een intern beveiligingsbeleid voor containerinfrastructuur.

Statistisch gezien is de urgentie duidelijk: uit onderzoek van Red Hat (2023) gaf 67% van de respondenten aan een beveiligingsincident te hebben meegemaakt in hun Kubernetes- of containeromgeving in het voorgaande jaar (Red Hat State of Kubernetes Security Report 2023).

Zero trust, secrets management en netwerksegmentatie

Een zelf beheerde Kubernetes-omgeving vereist dat u beveiligingscontroles die hyperscalers gedeeltelijk aanbieden als managed service, nu zelf implementeert en onderhoudt.

Voor secrets management (API-sleutels, certificaten, wachtwoorden) is HashiCorp Vault of zijn open-source equivalent OpenBao een bewezen keuze. Koppel Vault aan de Kubernetes-native serviceaccounts via de Vault Agent Injector of de Secrets Store CSI Driver. Sla nooit secrets op als Kubernetes Secret-objecten zonder aanvullende encryptie: standaard worden deze als base64-gecodeerde tekst opgeslagen in etcd, wat onvoldoende is voor gereguleerde omgevingen. Schakel etcd-encryptie at rest in en beperk toegang tot etcd tot uitsluitend het control plane.

Netwerksegmentatie binnen het cluster regelt u via Kubernetes NetworkPolicies in combinatie met een CNI-plugin (Container Network Interface) die deze daadwerkelijk afdwingt, zoals Cilium of Calico. Standaard staat Kubernetes alle pod-to-pod-communicatie toe: dat is een onacceptabel startpunt voor een gereguleerde omgeving. Implementeer een default-deny policy en sta alleen expliciete communicatiepaden toe.

Voor zero trust-toegang van buitenaf is een service mesh zoals Istio of Linkerd zinvol: deze implementeert mutual TLS (mTLS) tussen alle services, zodat ook interne oost-west-communicatie geauthenticeerd en versleuteld is. Combineer dit met een identity-aware proxy of een OIDC-gebaseerde toegangslaag voor gebruikerstoegang tot de Kubernetes API-server.

Let op: Role-Based Access Control (RBAC) in Kubernetes is standaard ingeschakeld, maar de standaardconfiguraties zijn vaak te ruim. Audit uw ClusterRoleBindings regelmatig en verwijder alle binding aan het system:masters-equivalent buiten break-glass-procedures.

NIS-2 en AVG-verplichtingen voor containerplatformen

NIS-2 (Richtlijn EU 2022/2555) en de AVG leggen gezamenlijk een set verplichtingen op die direct van toepassing zijn op hoe u een Kubernetes-cluster beheert.

NIS-2 vereist van belangrijke en essentiële entiteiten dat zij passende technische en organisatorische maatregelen nemen om risico’s voor de beveiliging van netwerk- en informatiesystemen te beheersen. Voor Kubernetes betekent dit concreet: gedocumenteerd patchbeheer (met aantoonbare SLA’s voor kritieke CVE’s), een configuratiebeheerprocedure (Infrastructure as Code via Helm of Kustomize, opgeslagen in een versiebeheerd Git-repository), en een gedocumenteerde incidentresponseprocedure die aansluit op de meldplicht van maximaal 24 uur voor significante incidenten.

De AVG vereist dat verwerkingen van persoonsgegevens worden gedocumenteerd in het verwerkingsregister en dat passende technische maatregelen aanwezig zijn. In een Kubernetes-context vertaalt dit zich naar: namespace-isolatie per verwerkingsactiviteit, auditlogging van alle API-aanroepen via de Kubernetes Audit API, en aantoonbare encryptie van data at rest en in transit.

IBM rapporteerde in 2023 dat 45% van alle datalekken cloudgebaseerde data betrof (IBM Cost of a Data Breach Report 2023). Tegelijkertijd registreerde ENISA in 2022-2023 meer dan 1.000 significante ransomware-incidenten in de EU, waarbij overheid en gezondheidszorg de meest getroffen sectoren waren (ENISA Threat Landscape 2023). Beide cijfers onderstrepen waarom compliance op platformniveau, niet alleen op applicatieniveau, noodzakelijk is.

Kostenefficiënt schalen zonder hyperscaler-voetafdruk

Een veelgehoord argument voor hyperscaler-managed Kubernetes is de lage instapkosten. On-premise vereist hardware-investering, maar die vergelijking is onvolledig zonder de totale kostprijs over drie tot vijf jaar mee te nemen.

Voor middelgrote overheidsorganisaties (50 tot 500 medewerkers) is een cluster van drie control plane-nodes en vier tot zes worker-nodes een realistische startconfiguratie. Met refurbished of tweedehands serversystemen (Dell PowerEdge, HPE ProLiant) en open-source software (RKE2 of K3s, Harbor, Longhorn voor gedistribueerde opslag) zijn de initiële hardware-kosten beheersbaar. Longhorn, eveneens een Rancher by SUSE-project, biedt gedistribueerde blokopslag die specifiek is ontworpen voor Kubernetes-omgevingen zonder externe SAN-afhankelijkheid.

Gebruik Infrastructure as Code consequent: Terraform of Ansible voor de provisionering van nodes, Helm-charts voor applicatiedeployments, en GitOps-tooling zoals Flux of Argo CD voor geautomatiseerde uitrol. Dit verlaagt de operationele last en maakt het cluster beheersbaar met een klein team. Automatische updates van Kubernetes-versies zijn via Rancher’s upgrade controller in te plannen buiten kantooruren, waarna auditlogs de compliance-documentatie automatisch aanvullen.

Voor organisaties die on-premise hardware niet willen beheren, bieden Europese co-locatiefaciliteiten (zoals die van EvoSwitch in Nederland of Green Mountain in Noorwegen) een alternatief waarbij u zelf de server beheert maar de fysieke infrastructuur uitbesteedt aan een aanbieder die volledig onder Europese rechtsmacht valt.

FAQ

Is een zelf beheerde Kubernetes-cluster per definitie veiliger dan Azure AKS of AWS EKS?

Niet automatisch. De veiligheid hangt af van hoe goed het cluster wordt geconfigureerd, gepatcht en gemonitord. Het voordeel is juridische soevereiniteit: u bepaalt wie toegang heeft en er is geen sprake van een buitenlandse wet zoals de CLOUD Act die uw provider kan dwingen data vrij te geven. Dat verschil is voor gereguleerde sectoren doorslaggevend.

Welke Kubernetes-distributie is het meest geschikt voor een kleine overheidsorganisatie?

K3s (Rancher by SUSE) is een lichtgewicht distributie die goed werkt op beperkte hardware en eenvoudig te onderhouden is. Voor organisaties met hogere compliance-eisen en behoefte aan geïntegreerde beveiligingsfuncties biedt Red Hat OpenShift meer ingebouwde controles, maar vereist meer resources en kennis. RKE2 zit hier tussenin en is bij uitstek geschikt voor organisaties met FIPS-vereisten.

Wat is een SBOM en waarom is het verplicht onder de Cyber Resilience Act?

Een Software Bill of Materials (SBOM) is een gestructureerde lijst van alle softwarecomponenten in een applicatie of containerimage, inclusief versies en licenties. Artikel 13 van de Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen om een SBOM op te stellen en beschikbaar te houden, zodat kwetsbaarheden in de toeleveringsketen snel kunnen worden opgespoord en gecommuniceerd.

Hoe verhoudt NIS-2 zich tot bestaande AVG-verplichtingen voor containerplatformen?

NIS-2 (Richtlijn EU 2022/2555) richt zich op de technische en organisatorische beveiligingsmaatregelen van het platform zelf, inclusief patchbeheer, toegangscontrole en incidentrapportage. De AVG regelt de rechtmatigheid van de verwerking van persoonsgegevens die via dat platform stromen. Beide kaders zijn van toepassing en vullen elkaar aan: een goed gedocumenteerde Kubernetes-omgeving helpt aan beide te voldoen.

Kan Harbor als containerregistry voldoen aan Europese soevereiniteitseisen?

Ja. Harbor is een open-source, OCI-conforme containerregistry die volledig on-premise of in een Europese co-locatiefaciliteit kan worden gehost. Harbor ondersteunt image scanning op kwetsbaarheden, role-based access control en signatuurverificatie via Notary v2, waardoor het geschikt is als soevereine vervanger van Docker Hub of Amazon ECR zonder enige afhankelijkheid van een buitenlandse provider.

Veelgestelde vragen

Is een zelf beheerde Kubernetes-cluster per definitie veiliger dan Azure AKS of AWS EKS?
Niet automatisch. De veiligheid hangt af van hoe goed het cluster wordt geconfigureerd, gepatcht en gemonitord. Het voordeel is juridische soevereiniteit: u bepaalt wie toegang heeft en er is geen sprake van een buitenlandse wet zoals de CLOUD Act die uw provider kan dwingen data vrij te geven. Dat verschil is voor gereguleerde sectoren doorslaggevend.
Welke Kubernetes-distributie is het meest geschikt voor een kleine overheidsorganisatie?
K3s (Rancher by SUSE) is een lichtgewicht distributie die goed werkt op beperkte hardware en eenvoudig te onderhouden is. Voor organisaties met hogere compliance-eisen en behoefte aan geu00efntegreerde beveiligingsfuncties biedt Red Hat OpenShift meer ingebouwde controles, maar vereist meer resources en kennis.
Wat is een SBOM en waarom is het verplicht onder de Cyber Resilience Act?
Een Software Bill of Materials (SBOM) is een gestructureerde lijst van alle softwarecomponenten in een applicatie of containerimage, inclusief versies en licenties. Artikel 13 van de Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen om een SBOM op te stellen en beschikbaar te houden, zodat kwetsbaarheden in de toeleveringsketen snel kunnen worden opgespoord.
Hoe verhoudt NIS-2 zich tot bestaande AVG-verplichtingen voor containerplatformen?
NIS-2 (Richtlijn EU 2022/2555) richt zich op de technische en organisatorische beveiligingsmaatregelen van het platform zelf, inclusief patchbeheer, toegangscontrole en incidentrapportage. De AVG regelt de rechtmatigheid van de verwerking van persoonsgegevens die via dat platform stromen. Beide kaders zijn van toepassing en vullen elkaar aan: een goed gedocumenteerde Kubernetes-omgeving helpt aan beide te voldoen.
Kan Harbor als containerregistry voldoen aan Europese soevereiniteitseisen?
Ja, Harbor is een open-source OCI-conforme containerregistry die volledig on-premise of in een Europese co-locatiefaciliteit kan worden gehost. Harbor ondersteunt image scanning op kwetsbaarheden, role-based access control en signatuurverificatie via Notary, waardoor het geschikt is als soevereine vervanger van Docker Hub of Amazon ECR.