Is uw Kubernetes-cluster veilig of gewoon actief?Standaard Kubernetes-configuraties geven prioriteit aan gebruiksgemak boven beveiliging. Zonder doelbewuste verharding zijn clusters kwetsbaar voor containerontsnappingen, escalatie van bevoegdheden, zijdelingse verplaatsing en gegevensdiefstal. Deze checklist omvat alle beveiligingscontroles die u moet implementeren voor productie-Kubernetes-omgevingen.
Belangrijkste afhaalrestaurants
- Standaard Kubernetes is niet beveiligd:Kant-en-klare configuraties maken geprivilegieerde containers, onbeperkte netwerktoegang en brede API servermachtigingen mogelijk.
- RBAC is je eerste verdediging:Beperk de API-servertoegang tot het minimum dat vereist is voor elk serviceaccount en elke gebruiker.
- Netwerkbeleid voorkomt zijwaartse beweging:Zonder netwerkbeleid kan elke pod met elke andere pod communiceren: een plat netwerk binnen uw cluster.
- Pod-beveiligingsnormen vervangen PSP:Pod Security Admission (PSA) dwingt beveiligingsbeperkingen af voor alle pods.
- Beveiligingskwesties in de toeleveringsketen:Controleer de herkomst van afbeeldingen, scan op kwetsbaarheden en dwing afbeeldingsbeleid af via toegangscontrole.
Kubernetes Beveiligingschecklist
API Serverbeveiliging
- Schakel RBAC in en schakel anonieme authenticatie uit
- Gebruik sterke authenticatie (OIDC, op certificaten gebaseerd) — geen basisauthenticatie of statische tokens
- Beperk de toegang tot de API-server tot bekende IP-bereiken (beheerde Kubernetes: gebruik geautoriseerde netwerken)
- Schakel auditregistratie in voor alle API serververzoeken
- Schakel alfa-/bètafuncties uit in productieclusters
- Toegangscontrollers configureren: PodSecurity, ResourceQuota, LimitRange
RBAC-best practices
- Volg de minste rechten: geen ClusterAdmin-bindingen voor serviceaccounts
- Gebruik waar mogelijk rollen op naamruimte in plaats van ClusterRoles
- Controleer RBAC regelmatig met tools als kubectl-who-can en rbac-lookup
- Verleen nooit wildcard-machtigingen (werkwoorden: ["*"], bronnen: ["*"])
- Beperk de toegang tot geheimen: geef alleen get/list voor geheimen aan pods die ze nodig hebben
- Gebruik aparte serviceaccounts per applicatie (niet het standaard serviceaccount)
Netwerkbeveiliging
- Implementeer standaard-deny NetworkPolicies in alle naamruimten
- Alleen het vereiste inkomend en uitgaand verkeer per toepassing toestaan
- Gebruik een CNI die NetworkPolicies ondersteunt (Calico, Cilium, Antrea)
- Versleutel de communicatie tussen pods met service mesh mTLS (Istio, Linkerd)
- Beperk het uitgaande verkeer naar bekende externe eindpunten (voorkom gegevensexfiltratie)
- Isoleer gevoelige werkbelastingen in speciale naamruimten met strikt beleid
Pod-beveiliging
- Schakel Pod-beveiligingstoegang in op naamruimteniveau (handhaving van een "beperkt" profiel)
- Voer containers uit als niet-root (runAsNonRoot: true)
- Gebruik het alleen-lezen rootbestandssysteem (readOnlyRootFilesystem: true)
- Laat alle mogelijkheden vallen, voeg alleen toe wat nodig is (drop: ["ALL"])
- Schakel privilege-escalatie uit (allowPrivilegeEscalation: false)
- Stel resourcelimieten (CPU, geheugen) in voor alle containers om misbruik van bronnen te voorkomen
- Koppel het serviceaccounttoken niet tenzij dit nodig is (automountServiceAccountToken: false)
Beeldbeveiliging
- Scan alle afbeeldingen op kwetsbaarheden vóór implementatie (Trivy, Snyk)
- Gebruik minimale basisimages (distroless, Alpine) om het aanvalsoppervlak te verkleinen
- Containerafbeeldingen ondertekenen en handtekeningen verifiëren bij toegang (cosign, notatie)
- Alleen afbeeldingen uit vertrouwde registers toestaan (afdwingen via toegangscontrole)
- Gebruik nooit de tag :latest - vastmaken aan specifieke afbeeldingssamenvattingen voor reproduceerbaarheid
- Regelmatig basisimages opnieuw opbouwen en bijwerken om beveiligingspatches op te nemen
Geheimenbeheer
- Bewaar geen geheimen in omgevingsvariabelen of ConfigMaps
- Gebruik extern geheimbeheer (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Als u Kubernetes Secrets gebruikt, schakelt u encryptie in rust in (EncryptionConfiguration)
- Roteer geheimen regelmatig met automatische rotatie via externe geheime operators
- Beperk RBAC-toegang tot geheimen: de meeste pods zouden niet alle geheimen moeten kunnen vermelden
Bewaking en detectie
- Schakel Kubernetes auditlogboekregistratie in en stuur deze door naar SIEM
- Implementeer runtime-beveiligingsmonitoring (Falco, Sysdig)
- Monitoren op: onverwachte procesuitvoering, netwerkverbindingen, bestandswijzigingen, escalatie van bevoegdheden
- Waarschuwing voor: nieuwe creatie van ClusterRoleBinding, geheime toegang door onverwachte peulen, container exec-opdrachten
- Implementeer schendingen van het Pod-beveiligingsbeleid als SIEM waarschuwingen
CIS Kubernetes Benchmark
Het Center for Internet Security (CIS) publiceert gedetailleerde beveiligingsbenchmarks voor Kubernetes. Gebruik kube-bench om uw cluster automatisch te evalueren aan de hand van CIS-benchmarks. Behandel alle kritieke en hoge bevindingen vóór productie-implementatie. Beheerde Kubernetes-services (EKS, AKS, GKE) verwerken bepaalde benchmarkitems automatisch, maar voor klantverantwoordelijke items is nog steeds configuratie vereist.
Hoe Opsio Kubernetes beveiligt
- Clusterbeveiligingsbeoordeling:We evalueren uw Kubernetes-clusters aan de hand van CIS-benchmarks en best practices van cloudproviders.
- Implementatie van verharding:We implementeren alle checklistitems, waaronder RBAC, netwerkbeleid, pod-beveiliging en monitoring.
- Runtime-bewaking:Onze SOC controleert Kubernetes clusters op beveiligingsgebeurtenissen en afwijkend gedrag.
- Beleidshandhaving:We zetten OPA/Gatekeeper of Kyverno in om het beveiligingsbeleid automatisch af te dwingen.
- Lopend beheer:Regelmatige beveiligingsbeoordelingen, herbeoordeling van CIS-benchmarks en updates van de beveiligingsconfiguratie.
Veelgestelde vragen
Wat is de belangrijkste Kubernetes-beveiligingscontrole?
Netwerkbeleid met standaard weigeren. Zonder netwerkbeleid kan elke pod met elke andere pod communiceren. Een aangetaste webtoepassingspod heeft rechtstreeks toegang tot de databasepod, de monitoringstack en de Kubernetes API-server. Standaard-deny-netwerkbeleid verkleint onmiddellijk de explosieradius van elk containercompromis.
Moet ik een servicemesh gebruiken voor beveiliging?
Service mesh (Istio, Linkerd) voegt mTLS toe tussen services, waardoor codering en authenticatie wordt geboden voor alle communicatie tussen pods. Als u gevoelige gegevens verwerkt of moet voldoen aan de nalevingsvereisten voor versleuteling tijdens de overdracht, is service mesh waardevol. Voor eenvoudigere omgevingen kan alleen netwerkbeleid voldoende zijn.
Hoe ga ik veilig om met geheimen in Kubernetes?
Gebruik een externe geheimenmanager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) met een Kubernetes geheimenoperator (External Secrets Operator, Vault Secrets Operator). Dit houdt geheimen buiten Git, zorgt voor auditlogboekregistratie, maakt rotatie mogelijk en centraliseert het geheimbeheer voor Kubernetes en niet-Kubernetes workloads.