Best practices voor Kubernetes-beveiliging: Hardening van build tot runtime

Kubernetes wordt geleverd met permissieve standaardinstellingen, dus clusterbeveiliging is jouw verantwoordelijkheid. Leer de best practices voor Kubernetes-beveiliging in de build-, deploy- en runtimefasen.

Wat is Kubernetes-beveiliging?

Kubernetes-beveiliging is de verzameling controles die u toepast op build, implementatie en runtime om een cluster, de workloads die erop draaien en de pipeline die het voedt te beschermen. Zonder deze controles kan één niet-geauthenticeerd verzoek uw volledige cluster overnemen. Dat was IngressNightmare, de kwetsbaarheid met ernstscore 9,8 die in maart 2025 werd bekendgemaakt in ingress-nginx, de controller die in meer dan 40% van de Kubernetes-clusters draait.

De admission webhook bevond zich op het pod-netwerk zonder authenticatie, en ingress-nginx leest standaard elke Secret in het cluster. Bereik het netwerk, bezit het cluster. Er was geen exploitketen nodig, geen gestolen wachtwoord: alleen permissieve standaardinstellingen die deden waarvoor ze waren geconfigureerd.

Die kloof, tussen wat Kubernetes standaard levert en wat een productiecluster nodig heeft, is wat hardening dicht. Kubernetes security best practices zijn hoe u die kloof sluit, fase voor fase, van de image die u bouwt tot de workload die u uitvoert. Omdat orkestratie uw workloads, secrets en east-west-verkeer centraliseert in één control plane, kan één enkele misconfiguratie elke service die u uitvoert blootstellen. Daarom ligt dat werk bij u en niet bij het platform.

Waarom is Kubernetes-beveiliging belangrijk?

Kubernetes hardent zichzelf niet. De CISA/NSA Kubernetes Hardening Guidance documenteert drie veelzeggende standaardinstellingen op elk nieuw cluster: anonieme aanmelding bij de API-server is ingeschakeld, Secrets worden onversleuteld opgeslagen in etcd en auditlogging staat uit. Het shared-responsibility-model legt vier controles in uw handen: role-based access control (RBAC), netwerkbeleid, secrets-versleuteling en runtime-controles. De cloudprovider zal deze niet voor u configureren, en de distributie evenmin. Omdat deze controles in uw configuratie leven en in de loop van de tijd afwijken, verifiëren teams ze steeds vaker continu met Kubernetes security posture management in plaats van handmatig te auditen.

Een aanvaller die een niet-geauthenticeerde API-server bereikt, kan elke Secret in etcd lezen, een pod op elke node plannen en zich tussen namespaces verplaatsen terwijl auditlogging stil blijft, waardoor het eerste signaal dat u krijgt de inbreuk zelf kan zijn. Eén blootgesteld endpoint wordt binnen enkele minuten clusterbrede toegang, hetzelfde patroon dat IngressNightmare volgde.

De inzet schaalt mee met adoptie. De jaarlijkse Cloud Native Survey van de Cloud Native Computing Foundation (CNCF) meldt dat 82% van de containergebruikers Kubernetes nu in productie draait, tegenover 66% in 2023. Omdat clusters zich in het pad bevinden van klantgerichte services, gereguleerde data en auditverplichtingen, verandert één gemiste controle in blootstelling aan datalekken, mislukte audits en meldingsplichtige incidenten waarvoor uw team verantwoording moet afleggen. Weten wat er op het spel staat is pas van belang zodra u weet welke onderdelen van het cluster dat risico dragen.

Kerncomponenten van een Kubernetes-cluster

U kunt niet hardenen wat u niet hebt geïnventariseerd. Elke component brengt een specifieke beveiligingsblootstelling met zich mee, en inzicht in die blootstelling vertelt u waar uw controles moeten worden toegepast.

Control plane-componenten:

• API-server: Elke kubectl-opdracht die u uitvoert, elke admission webhook en elk serviceaccount-tokenverzoek gaat via de API-server. Ongeautoriseerde toegang hier betekent volledige controle over het cluster.
• etcd: Slaat alle clusterstatus, configuratie en Secrets op waarvan u afhankelijk bent. Leestoegang tot etcd is functioneel gelijk aan root op uw volledige cluster.
• Scheduler en controller manager: Een gecompromitteerde scheduler kan workloads op specifieke nodes plaatsen om lokale resources uit te buiten. Manipulatie van controllers kan implementaties, replicaaantallen en resourcetoewijzingen ongemerkt wijzigen.

Worker node-componenten:

• kubelet: De agent op elke node die pod-specificaties uitvoert. Als u de kubelet-API blootgesteld laat, kan een aanvaller containers maken of opdrachten direct op de node uitvoeren.
• kube-proxy: Beheert netwerkregels voor serviceroutering. Verkeerd geconfigureerde proxyregels kunnen uw interne services blootstellen aan extern verkeer.
• Container runtime: Voert containers uit op de host. Een kwetsbare runtime stelt elke container die deze ondersteunt en de host zelf bloot, zoals NIST SP 800-190 opmerkt.

Pods, containers en netwerken:

• Pods delen netwerk-namespaces, dus een gecompromitteerde container in een pod kan zonder netwerkcontroles toegang krijgen tot andere containers in dezelfde pod. Zonder NetworkPolicy-objecten communiceren uw pods in verschillende namespaces standaard vrij met elkaar. 
• Containerimages en infrastructure-as-code (IaC)-templates komen uw cluster binnen vanuit externe registries, en een vergiftigde image die in productie wordt opgehaald verspreidt zich over elke node die deze plant. Door elke component te koppelen aan zijn blootstelling ziet u precies waar de hardening-controles in deze gids van toepassing zijn.

Hoe Kubernetes-beveiliging werkt in de build-to-runtime-levenscyclus

U beveiligt Kubernetes via een continue workflow, niet met een eenmalige controle. Elke fase dwingt een andere categorie controles af, en de output van de ene fase wordt de input voor de volgende. Dit gebeurt er bij elke stap.

1. Buildtijd: U scant containerimages op bekende kwetsbaarheden, valideert IaC-templates tegen beleid, ondertekent images cryptografisch en genereert een software bill of materials (SBOM). Deze preventieve controles stoppen problemen bij de bron, voordat een artefact kan worden gepland.
2. Implementeren en configureren: Wanneer u een workload indient, evalueren admission controllers deze tegen beleid vóór planning. RBAC bepaalt wie resources kan maken, wijzigen of lezen, en netwerkbeleid definieert welke pods kunnen communiceren. De image die u tijdens de build hebt ondertekend, is hier alleen beschermd als admission control de handtekening daadwerkelijk controleert.
3. Configuratie van control plane en nodes: U configureert de API-server, etcd, kubelet en het node-OS om te beperken wat wordt blootgesteld. Authenticatie, autorisatie en versleuteling bepalen de vertrouwensgrens waarop elke andere fase vertrouwt, dus een zwakke control plane verzwakt alles stroomafwaarts.
4. Runtime: Monitoringtools letten op gedragsafwijkingen, configuratiedrift en bekende aanvalspatronen in uw draaiende workloads, terwijl seccomp- en AppArmor-profielen beperken welke systeemaanroepen uw containers kunnen doen. Runtime is ook waar u de hiaten opvangt die build en implementatie hebben gemist.

U sluit de lus wanneer runtimebevindingen terugvloeien naar uw buildfase als bijgewerkte images, bijgewerkte IaC en bijgewerkt admission-beleid. De levenscyclus werkt alleen wanneer elke overdracht standhoudt. Dit is wat één mislukte overdracht kost.

Impact van een gecompromitteerd Kubernetes-cluster

Wanneer uw cluster wordt gecompromitteerd, reiken de gevolgen veel verder dan één enkele workload.

• Laterale beweging en blast radius: Uw clusters draaien tientallen tot duizenden pods die netwerkconnectiviteit delen. Een aanvaller die toegang krijgt tot een van uw pods kan zich lateraal verplaatsen over namespaces en nodes wanneer RBAC te ruime rechten heeft en netwerkbeleid ontbreekt.
• Blootstelling van secrets: etcd bevat uw API-sleutels, databasegegevens, TLS-certificaten en servicetokens. Omdat Secrets standaard niet versleuteld zijn, kan een aanvaller met leestoegang tot etcd elke credential in uw cluster extraheren.
• Verspreiding via de supply chain: Een vergiftigde containerimage die via uw continuous integration- en continuous delivery-pipeline (CI/CD) wordt geïmplementeerd, bereikt elke node die deze plant. In clusters met honderden replica's kan één gecompromitteerde image binnen enkele minuten kwaadaardige code uitvoeren in uw volledige infrastructuur.
• Compromittering van workloads en data: Uw productiedatabases, klantgerichte applicaties en interne services draaien naast elkaar. Een inbreuk in één workload kan gevoelige data blootstellen, de beschikbaarheid van services verstoren of persistentie voor toekomstige aanvallen vestigen.
• Compliance- en regelgevingsblootstelling: Als uw clusters betalingsgegevens, medische dossiers of overheidsworkloads verwerken, vallen ze onder vereisten van PCI DSS, HIPAA, FedRAMP en SOC 2. Een verkeerd geconfigureerd cluster dat een audit niet doorstaat, kan leiden tot operationele stilleggingen en financiële sancties.

Hardening verkleint de blast radius van elke afzonderlijke compromittering, verkort incident response-tijdlijnen en levert het auditbewijs dat uw complianceprogramma vereist. Dat in de praktijk bereiken is moeilijker dan het klinkt, om redenen die specifiek zijn voor hoe Kubernetes draait.

Uitdagingen bij het beveiligen van Kubernetes

Kubernetes-beveiliging is operationeel moeilijk, zelfs voor uw meest ervaren teamleden. De vluchtigheid van het platform, het declaratieve configuratiemodel en de gedistribueerde architectuur creëren frictie waar statische beveiligingstools niet voor zijn gebouwd.

• Vluchtige, voortdurend veranderende workloads: Pods worden continu gemaakt, vernietigd en opnieuw gepland. Een posture-snapshot van uw cluster om 9:00 uur weerspiegelt mogelijk niet de status om 9:05 uur.
• Zichtbaarheidslacunes in draaiende containers: Containers delen de hostkernel maar isoleren hun processen, bestandssystemen en netwerkstacks. Standaard hostgebaseerde monitoringtools missen vaak de context om normaal containergedrag te onderscheiden van kwaadaardige activiteit.
• Configuratiecomplexiteit en drift: Een productiecluster omvat honderden YAML-manifests, RBAC-bindingen en admission-regels. Drift tussen wat u in Git declareert en wat in uw cluster draait, introduceert niet-gevolgde blootstelling.
• Multi-cluster- en multi-cloud-sprawl: Als u clusters draait over Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP) en on-premises omgevingen, moet u consistent beleid afdwingen over verschillende managed services heen, elk met zijn eigen shared-responsibility-grens.
• Gefragmenteerde tooling: Imagescanning, RBAC-beheer, afdwinging van netwerkbeleid, runtimemonitoring en compliancerapportage vereisen vaak afzonderlijke tools zonder gedeeld datamodel. Alertcorrelatie komt op u neer.
• Vaardigheden en organisatorische frictie: De gespecialiseerde vaardigheden zijn schaars, en uit de CNCF-enquête van 2025 bleek dat voor het eerst de belangrijkste belemmering voor cloud-native adoptie organisatorisch in plaats van technisch is: interne communicatie, teamdynamiek en afstemming van leiderschap. Controles worden niet toegepast omdat niemand er eigenaar van is.

Deze beperkingen bepalen zowel uw toolkeuzes als uw wervingsprioriteiten, en ze verklaren waarom dezelfde fouten zich over clusters heen blijven herhalen.

Veelvoorkomende fouten in Kubernetes-beveiliging

Specifieke anti-patronen van operators creëren de blootstellingen die aanvallers uitbuiten. Identificeer en elimineer elk van deze in uw clusters:

• Privileged of root-containers uitvoeren. Privileged containers omzeilen alle isolatie van de Linux-kernel. Een container die als root draait met allowPrivilegeEscalation: true kan ontsnappen naar de host.
• cluster-admin of wildcard-RBAC toekennen. Wildcardmachtigingen (resources: ["*"], verbs: ["*"]) worden automatisch uitgebreid naar API-resources die nog niet bestaan. De Kubernetes-documentatie bestempelt dit patroon als "DO NOT USE."
• Default-allow-netwerken laten bestaan. Zonder NetworkPolicy-objecten communiceren uw pods in verschillende namespaces vrij met elkaar.
• Secrets opslaan in plaintext-manifests. Credentials committen naar Git of ze doorgeven als omgevingsvariabelen stelt ze bloot in crashdumps, logs en shellgeschiedenis.
• Image- en IaC-scanning overslaan. Niet-gescande images implementeren laat kwetsbaarheden ongecontroleerd productie bereiken.
• Hardening behandelen als een eenmalige poort. Een cluster dat bij bootstrap is gehardend, drijft af naarmate uw teams workloads toevoegen en configuraties wijzigen. Zonder continue afdwinging verslechtert de posture.
• Node- en control-plane-configuratie negeren. Anonieme aanmelding bij de API-server ingeschakeld laten, etcd-versleuteling overslaan en auditlogging weglaten zijn standaardtoestanden die uw expliciete remediatie vereisen.

Elk van deze punten is corrigeerbaar met de onderstaande praktijken. Behandel ze als een checklist van blootstellingen die u moet uitfaseren voordat u extra workloads naar het cluster opschaalt.

Kubernetes security best practices

Deze Kubernetes security best practices vormen de operationele kern van Kubernetes-clusterhardening, georganiseerd volgens dezelfde vier levenscyclusfasen die hierboven zijn geïntroduceerd. Werk ze in volgorde door, omdat elke fase ervan uitgaat dat de vorige standhoudt.

De buildfase beveiligen

1. Scan images op kwetsbaarheden voordat ze een registry bereiken. Integreer container image scanning in uw CI-pipelines zodat kwetsbare images nooit implementeerbare artefacten worden.
2. Gebruik minimale of distroless base images. Distroless images bevatten alleen uw applicatie en de runtime-afhankelijkheden ervan, zonder shell, pakketbeheerder of onnodige binaries. Pin images aan expliciete versiesuffixen (e.g., gcr.io/distroless/static-debian13) en gebruik nooit de latest tag.
3. Onderteken en verifieer images. Gebruik Cosign of Notary om images in CI te ondertekenen. Configureer admission controllers om niet-ondertekende of niet-geverifieerde images tijdens implementatie te weigeren.
4. Scan IaC en Kubernetes-manifests. Valideer Terraform, Helm charts en ruwe YAML tegen beveiligingsbeleid voordat ze uw cluster bereiken.
5. Genereer een SBOM voor elke image om herkomst vast te leggen en het volgen van kwetsbaarheden na implementatie te ondersteunen.
6. Houd secrets uit images. Bak credentials, API-sleutels of certificaten nooit in containerimages of Dockerfiles.

Deze buildfasecontroles houden kwetsbare en niet-ondertekende artefacten uit de pipeline voordat iets kan draaien. Een image die deze controles doorstaat, is nog steeds alleen veilig als het cluster deze correct toelaat, en daar neemt de configuratie tijdens implementatie het over.

Clusterconfiguratie en implementatie hardenen

Deze Kubernetes RBAC best practices en netwerkcontroles zetten beleid tijdens implementatie om in afgedwongen guardrails.

1. Pas RBAC met least privilege toe. Maak namespace-scoped Roles met expliciete verbs en resourcenamen. Elimineer wildcard-toekenningen. Beperk cluster-admin tot break-glass-gebruik. Stel automountServiceAccountToken: false in op serviceaccounts die geen API-toegang nodig hebben.

2. Dwing default-deny-netwerkbeleid af. Pas een default-deny-all Netwenforce modus met het restrictedorkPolicy toe, zowel ingress als egress, op elke namespace bij bootstrap. Voeg expliciete allow-regels per workload toe, inclusief een DNS-egress-uitzondering op UDP-poort 53.

3. Dwing de Restricted Pod Security Standard af. Gebruik Pod Security Admission in enforce-modus met het restricted level voor productienamespaces. Dit blokkeert privileged containers, vereist runAsNonRoot, verplicht seccomp-profielen en beperkt volumetypen.

4. Voeg admission control toe met OPA Gatekeeper of Kyverno. Dwing readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, allowlists voor imageregistries en capability drop-ALL-beleid af. Gebruik eerst dryrun-modus om bestaande workloads te auditen voordat u overschakelt naar deny.

5. Beheer Secrets in een externe store met etcd-versleuteling at rest. Gebruik de key management service (KMS) v2-provider voor envelope-encryptie en mount Secrets als volumes via de Secrets Store CSI Driver, die tmpfs gebruikt zodat geheime data nooit de nodedisk bereikt. Vermijd het doorgeven van Secrets als omgevingsvariabelen.

6. Stel resourcelimieten in. Definieer CPU- en geheugenrequests en -limieten op elke container om resource-uitputting te voorkomen.

Met afgedwongen beleid tijdens implementatie draaien uw workloads met least privilege en default-deny-netwerken. Het vertrouwen waarop die guardrails steunen, zit nog steeds in de control plane en de nodes eronder, dus harden die vervolgens.

De control plane en worker nodes beschermen

De control plane is de enige plek waar één zwakke instelling alles andere raakt. Configureer elk van deze punten en verifieer ze vervolgens volgens een schema in plaats van slechts één keer bij bootstrap.

Hardening-stap	Wat te configureren	Bron
Toegang tot API-server	Vereis sterke authenticatie en wederzijdse TLS; houd de API-server van het openbare internet af.	CIS Benchmark
Anonieme auth	Stel --anonymous-auth=false in	CISA/NSA guidance
Auditlogging	Schakel API-audit-, metric-, applicatie- en seccomp-logs in; aggregeer ze buiten het cluster en alerteer erop	CISA/NSA guidance
etcd	Versleutel at rest, vereis wederzijdse TLS en isoleer achter een firewall die alleen API-servers kunnen bereiken	CIS Benchmark
kubelet	Beperk API-toegang, schakel alleen-lezen-poorten uit, pas configuraties op nodeniveau toe	CIS Benchmark
Node-basislijn	Lijn control plane, etcd en nodes uit met de CIS Kubernetes Benchmark voor uw release; scan volgens een continue cadans	CIS Benchmark
Versies	Patch Kubernetes, het node-OS en de container runtime volgens een regelmatige cadans	—

Met de control plane vergrendeld en de nodes gepatcht, houdt de basis stand. Een live workload kan nog steeds afwijken van de gedeclareerde status of van binnenuit worden aangevallen, en runtime-controles zijn wat dat opvangt.

Runtime-beveiliging en dreigingsdetectie

Sterke Kubernetes runtime security vangt op wat statische controles niet kunnen.

1. Monitor runtimegedrag. Implementeer een containernative runtime-beveiligingstool die let op afwijkende syscalls, onverwachte procesuitvoering, netwerkverbindingen en bestandswijzigingen. NIST SP 800-190 stelt dat traditionele intrusion prevention system (IPS)- en web application firewall (WAF)-tools geen geschikte bescherming bieden voor containers.
2. Detecteer configuratiedrift. Vergelijk draaiende workloads met hun gedeclareerde status in Git. Markeer containers die zijn afgeweken van hun oorspronkelijke image of configuratie.
3. Pas seccomp- en AppArmor- of SELinux-profielen toe. Gebruik minimaal RuntimeDefault-seccomp-profielen. Rol aangepaste profielen eerst uit op een subset van nodes en breid daarna clusterbreed uit na validatie.
4. Gebruik alleen-lezen-rootbestandssystemen en verwijder onnodige capabilities. Stel readOnlyRootFilesystem: true en capabilities: drop: [ALL] in op elke productiecontainer.
5. Dwing runAsNonRoot af. Vereis runAsNonRoot: true in pod-beveiligingscontexten. Bouw images zodat ze tijdens buildtijd als niet-rootgebruiker worden uitgevoerd in plaats van uitsluitend te vertrouwen op overrides tijdens implementatie.
6. Schakel autonome respons en continue auditlogging in. Correlleer runtime-alerts met auditlogs om aanvalstijdlijnen te reconstrueren. Voer bevindingen terug in buildtijdbeleid om de lus te sluiten.

Samen leveren deze vier fasen een continu gehardend cluster op. Branchebenchmarks beschrijven hoe "correct geconfigureerd" eruitziet in elke fase, en u moet uw cluster daaraan meten.

Kubernetes-beveiligingsstandaarden en compliance

Door de branche erkende benchmarks operationaliseren de hierboven beschreven praktijken en leveren het auditbewijs dat uw Kubernetes-complianceprogramma vereist.

Standaard	Scope	Relevantie
CIS Kubernetes Benchmark	Control plane, etcd, worker nodes, beleid	Erkend door PCI DSS, FedRAMP, SOC 2, FISMA en het NIST National Checklist Program
CISA/NSA Kubernetes Hardening Guidance	Build, implementatie, netwerk, RBAC, logging, runtime	Gezaghebbende overheidsbasislijn voor federale clusters en clusters voor kritieke infrastructuur
Pod Security Standards	Privilegebeperkingen op podniveau over drie niveaus	Ingebouwd Kubernetes-afdwingingsmechanisme; sluit direct aan op Tabel I van de CISA/NSA-guidance
NIST SP 800-190	Beveiliging van de containerlevenscyclus	Koppelt containercontroles aan NIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4 en andere)

Nu Kubernetes het standaard productieplatform is, behandelen complianceframeworks Kubernetes-specifieke controles steeds vaker als een afzonderlijk auditdomein in plaats van als een subset van algemene infrastructuurbeveiliging. 

Platformspecifieke benchmarks, zoals de CIS GKE Benchmark en de CIS OpenShift Benchmark, breiden de algemene benchmark uit met managed-service-specifieke controles. De standaarden kennen is de basislijn. De moeilijkere vraag is waar Kubernetes-beveiliging hierna naartoe gaat.

Toekomstige trends in Kubernetes-beveiliging

De controles die u vandaag implementeert, staan op verschuivende grond, en drie trends hervormen hoe teams Kubernetes security best practices benaderen.

1. AI-workloads verplaatsen het aanvalsoppervlak. Nu clusters de standaardomgeving worden voor AI- en machine-learningworkloads, worden GPU-planning, modelartefacten en grote trainingsdatasets nieuwe doelwitten. Het beveiligen van de data- en model-supply chain wordt onderdeel van clusterhardening, geen afzonderlijk aandachtspunt.
2. Integriteit van de software-supply chain wordt verplicht. SBOM-generatie, ondertekende artefacten en provenance-attestatie verschuiven van optionele volwassenheidsindicatoren naar basisverwachtingen in gereguleerde sectoren en overheidsinkoop.
3. Autonome runtimeverdediging vervangt handmatige triage. Het volume en de snelheid van clusteractiviteit overstijgen menselijke beoordeling. Behavioral AI die normaal van afwijkende workloadactiviteit onderscheidt en reageert zonder op een analist te wachten, verschuift van onderscheidende factor naar standaard.

Elke trend wijst in dezelfde richting: meer automatisering eerder in de levenscyclus en meer autonomie tijdens runtime, en dat is waar platformtooling zijn waarde bewijst.

Versterk Kubernetes-beveiliging met SentinelOne

De native Kubernetes-controles die deze gids behandelt, RBAC, NetworkPolicy, Pod Security Standards, etcd-versleuteling en auditlogging, vormen de basis van clusterhardening. SentinelOne voegt daar posture management, supply-chain-scanning, K8s admission control en runtime-dreigingsdetectie bovenop toe, elk gekoppeld aan een zwakte die deze gids benoemt.

Singularity Cloud Security scant Kubernetes-clusters voordat ze ooit draaien. Scanning tijdens buildtijd integreert direct met CI/CD-pipelines, versiebeheersystemen en containerregistries. Het controleert op bekende kwetsbaarheden en meer dan 750 typen blootgestelde secrets. Dezelfde scan omvat infrastructure-ascode-templates, waaronder Terraform, Helm, CloudFormation en Kubernetes YAML, om beleidsschendingen vroegtijdig op te sporen. Een Kubernetes Admission Controller fungeert als de laatste poortwachter bij de API-server en blokkeert ongeautoriseerde of bekend kwaadaardige images voordat ze worden geïmplementeerd.

Kubernetes Security Posture Management (KSPM) dicht zichtbaarheidslacunes in het cluster. Het bouwt een uniforme inventaris op over clusters, nodes, namespaces en deployments en brengt vervolgens te permissieve toegang en risicovolle configuraties aan het licht. De Offensive Security Engine™ simuleert vervolgens realistische aanvallen en bevestigt via Verified Exploit Paths™ welke misconfiguraties aanvallers daadwerkelijk kunnen bereiken. Securityteams prioriteren wat uitbuitbaar is in plaats van elke bevinding te triëren. Dezelfde rules engine ondersteunt de Admission Controller, zodat beleid consistent blijft van posture tot implementatie.

Tijdens runtime detecteert Singularity Cloud Workload Security, gebouwd op extended Berkeley Packet Filter (eBPF), afwijkend gedrag op machinesnelheid. Geautomatiseerde reacties beëindigen kwaadaardige processen en plaatsen geïnfecteerde bestanden in quarantaine zonder op een analist te wachten. Graph Explorer visualiseert relaties over het Kubernetes-aanvalsoppervlak, zodat teams precies zien wat is blootgesteld. Wanneer runtimedetectie een kwaadaardige image markeert, wordt die bevinding automatisch teruggekoppeld naar de Admission Controller. De image wordt dan geblokkeerd voor elke toekomstige implementatie, waardoor één detectie verandert in blijvend beleid. Purple AI brengt natuurlijke-taal threat hunting en gebeurtenissamenvattingen naar uw cloud-workloadtelemetrie op één data lake, zodat analisten in gewone taal query's uitvoeren in plaats van tussen tools te schakelen.

Bekijk waar uw clusters in productie zijn blootgesteld. Vraag een SentinelOne-demo aan om Kubernetes posture management en runtime-dreigingsdetectie in uw eigen omgeving door te nemen.

Bekijk een rondleiding

AI-gestuurde cloud workload-bescherming (CWPP) voor servers, VM's en containers, die runtime-bedreigingen in realtime detecteert en stopt.

Belangrijkste conclusies

Kubernetes wordt geleverd met permissieve standaardinstellingen die clusterbeveiliging in uw handen leggen. De Kubernetes security best practices in deze gids beslaan vier fasen: imagescanning en ondertekening tijdens build, RBAC en NetworkPolicy tijdens implementatie, etcd-versleuteling en auditlogging in de control plane en gedragsmonitoring tijdens runtime. 

Lijn uw configuratie uit met de CIS Benchmark en CISA/NSA-guidance, elimineer de hierboven geïdentificeerde veelvoorkomende fouten en sluit de lus door runtimebevindingen terug te voeren naar buildtijdbeleid. Als u dat bereikt, stopt u met gissen. U kunt op elke dag naar elke namespace wijzen en laten zien wat wordt afgedwongen, wat is afgedreven en wat u eraan hebt gedaan.

Veelgestelde vragen

Welke Kubernetes-instellingen zijn standaard onveilig?

Drie instellingen worden onveilig geleverd op elke nieuwe Kubernetes-cluster. De CISA/NSA Kubernetes Hardening Guidance v1.2 documenteert deze: anonieme API-serveraanmelding is ingeschakeld, Secrets worden onversleuteld opgeslagen in etcd en auditlogging is uitgeschakeld. 

Pod-naar-pod-communicatie is onbeperkt zonder NetworkPolicy-objecten. Je moet deze zelf hardenen. Noch de cloudprovider noch de Kubernetes-distributie past deze controles voor je toe onder het model van gedeelde verantwoordelijkheid.

Wat is het verschil tussen Kubernetes-beveiliging en containerbeveiliging?

Containerbeveiliging en Kubernetes-beveiliging werken op verschillende lagen van dezelfde stack. Containerbeveiliging richt zich op de image en containerinstantie: kwetsbaarheidsscanning, runtime-isolatie, het verwijderen van capabilities en bescherming van de hostkernel. 

Kubernetes-beveiliging omvat zowel afzonderlijke containers als het cluster eromheen, met toevoeging van RBAC, admission control, netwerkbeleid, etcd en auditlogging van orkestratie. Containerbeveiliging valt binnen de bredere discipline van Kubernetes-beveiliging.

Hoe verhouden Pod Security Standards zich tot het verouderde Pod Security Policies?

Pod Security Policies (PSP's) werden verouderd verklaard in Kubernetes v1.21 en verwijderd in v1.25. Pod Security Standards (PSS) definiëren drie beleidsniveaus (Privileged, Baseline, Restricted) en worden afgedwongen door Pod Security Admission (PSA), een ingebouwde admission controller die beleid toepast op naamruimteniveau via labels. 

PSA werd stabiel in v1.25. Als je cluster v1.25 of later draait en je PSA niet hebt geconfigureerd, werk je zonder de afdwingingslaag op podniveau.

Welke compliance-benchmarks zijn van toepassing op Kubernetes-clusters?

Vier primaire complianceframeworks zijn van toepassing op Kubernetes-clusters. De CIS Kubernetes Benchmark wordt erkend door PCI DSS, FedRAMP, SOC 2 en FISMA. De CISA/NSA Kubernetes Hardening Guidance dient als de overheidsbaseline. 

NIST SP 800-190 koppelt containercontroles aan de controlfamilies van NIST SP 800-53 Rev 5. Pod Security Standards bieden het ingebouwde afdwingingsmechanisme dat rechtstreeks aansluit op de CISA/NSA-richtlijnen.

Verzorgen beheerde services zoals EKS, AKS en GKE de clusterbeveiliging voor je?

Beheerde Kubernetes-services verzorgen de beschikbaarheid van het control plane, patching en een deel van de infrastructuurbeveiliging. U blijft verantwoordelijk voor RBAC-beleid, NetworkPolicy-objecten, Pod Security Admission, Secrets-versleuteling en runtime-monitoring. 

Het shared-responsibility-model is van toepassing: de provider beveiligt de control plane-infrastructuur en u beveiligt de workloads, configuratie en toegangscontroles. Platformspecifieke CIS Benchmarks documenteren de aanvullende controles die u op elke beheerde service moet toepassen.