Er din Kubernetes-klynge sikker, eller kører den bare?Standard Kubernetes-konfigurationer prioriterer brugervenlighed frem for sikkerhed. Uden bevidst hærdning er klynger sårbare over for containerudslip, privilegieeskalering, sideværts bevægelse og datatyveri. Denne tjekliste dækker enhver sikkerhedskontrol, du skal implementere til produktions Kubernetes miljøer.
Key Takeaways
- Standard Kubernetes er ikke sikker:Out-of-the-box-konfigurationer tillader privilegerede containere, ubegrænset netværksadgang og brede API-servertilladelser.
- RBAC er dit første forsvar:Begræns API serveradgang til det minimum, der kræves for hver tjenestekonto og bruger.
- Netværkspolitikker forhindrer lateral bevægelse:Uden netværkspolitikker kan hver pod kommunikere med hver anden pod - et fladt netværk inde i din klynge.
- Pod-sikkerhedsstandarder erstatter PSP:Pod Security Admission (PSA) håndhæver sikkerhedsbegrænsninger på alle pods.
- Supply chain sikkerhed spørgsmål:Bekræft billedets oprindelse, scan for sårbarheder, og håndhæv billedpolitikker gennem adgangskontrol.
Kubernetes Sikkerhedstjekliste
API Serversikkerhed
- Aktiver RBAC og deaktiver anonym godkendelse
- Brug stærk godkendelse (OIDC, certifikatbaseret) — ikke grundlæggende godkendelse eller statiske tokens
- Begræns API serveradgang til kendte IP-områder (administreret Kubernetes: brug autoriserede netværk)
- Aktiver revisionslogning for alle API serveranmodninger
- Deaktiver alfa/beta-funktioner i produktionsklynger
- Konfigurer adgangscontrollere: PodSecurity, ResourceQuota, LimitRange
RBAC bedste praksis
- Følg mindste privilegium: ingen ClusterAdmin-bindinger for tjenestekonti
- Brug navnespacede roller i stedet for ClusterRoles hvor det er muligt
- Revider RBAC regelmæssigt med værktøjer som kubectl-who-can og rbac-lookup
- Giv aldrig jokertegntilladelser (verber: ["*"], ressourcer: ["*"])
- Begræns adgangen til hemmeligheder — giv kun få/liste over hemmeligheder til pods, der har brug for dem
- Brug separate tjenestekonti pr. applikation (ikke standardtjenestekontoen)
Netværkssikkerhed
- Implementer default-deny NetworkPolicies i alle navneområder
- Tillad kun nødvendig ind- og udgående trafik pr. applikation
- Brug en CNI, der understøtter NetworkPolicies (Calico, Cilium, Antrea)
- Krypter inter-pod kommunikation med service mesh mTLS (Istio, Linkerd)
- Begræns udgang til kendte eksterne endepunkter (forhindrer dataeksfiltrering)
- Isoler følsomme arbejdsbelastninger i dedikerede navnerum med strenge politikker
Pod Security
- Aktiver Pod Security Admission på navnerumsniveau (håndhæv "begrænset" profil)
- Kør containere som ikke-root (runAsNonRoot: true)
- Brug skrivebeskyttet rodfilsystem (readOnlyRootFilesystem: true)
- Drop alle muligheder, tilføj kun det, der er nødvendigt (slip: ["ALL")
- Deaktiver rettighedseskalering (allowPrivilegeEscalation: false)
- Indstil ressourcegrænser (CPU, hukommelse) på alle containere for at forhindre ressourcemisbrug
- Monter ikke tjenestekontotokenet, medmindre det er nødvendigt (automountServiceAccountToken: false)
Billedsikkerhed
- Scan alle billeder for sårbarheder før implementering (Trivy, Snyk)
- Brug minimale basisbilleder (distroless, Alpine) for at reducere angrebsoverfladen
- Signer containerbilleder og bekræft signaturer ved optagelse (cosign, notation)
- Tillad kun billeder fra betroede registre (håndhæv gennem adgangskontrol)
- Brug aldrig :nyeste tag — fastgør til specifikke billedsammendrag for reproducerbarhed
- Genopbyg og opdater regelmæssigt basisbilleder for at inkorporere sikkerhedsrettelser
Secrets Management
- Gem ikke hemmeligheder i miljøvariabler eller ConfigMaps
- Brug ekstern hemmelighedsstyring (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Hvis du bruger Kubernetes Secrets, skal du aktivere kryptering i hvile (EncryptionConfiguration)
- Roter hemmeligheder regelmæssigt med automatiseret rotation gennem eksterne hemmelige operatører
- Begræns RBAC-adgang til hemmeligheder — de fleste pods burde ikke være i stand til at vise alle hemmeligheder
Overvågning og detektion
- Aktiver Kubernetes revisionslogning og videresend til SIEM
- Implementer runtime sikkerhedsovervågning (Falco, Sysdig)
- Overvåg for: uventet proceskørsel, netværksforbindelser, filændringer, privilegieeskalering
- Advarsel om: ny ClusterRoleBinding-oprettelse, hemmelig adgang med uventede pods, container exec-kommandoer
- Implementer Pod Security Policy-overtrædelser som SIEM-advarsler
CIS Kubernetes Benchmark
Center for Internet Security (CIS) udgiver detaljerede sikkerhedsbenchmarks for Kubernetes. Brug kube-bench til automatisk at evaluere din klynge i forhold til CIS-benchmarks. Håndter alle kritiske og høje fund før produktionsinstallation. Administrerede Kubernetes-tjenester (EKS, AKS, GKE) håndterer nogle benchmark-elementer automatisk, men kundeansvarlige varer kræver stadig konfiguration.
Hvordan Opsio sikrer Kubernetes
- Klyngesikkerhedsvurdering:Vi evaluerer dine Kubernetes-klynger i forhold til CIS-benchmarks og bedste praksis fra cloududbydere.
- Udførelse af hærdning:Vi implementerer alle tjeklistepunkter inklusive RBAC, netværkspolitikker, pod-sikkerhed og overvågning.
- Kørselsovervågning:Vores SOC overvåger Kubernetes-klynger for sikkerhedshændelser og unormal adfærd.
- Håndhævelse af politik:Vi implementerer OPA/Gatekeeper eller Kyverno for at håndhæve sikkerhedspolitikker automatisk.
- Løbende ledelse:Regelmæssige sikkerhedsgennemgange, CIS-benchmark-revurdering og sikkerhedskonfigurationsopdateringer.
Ofte stillede spørgsmål
Hvad er den vigtigste Kubernetes sikkerhedskontrol?
Netværkspolitikker med standard-afvisning. Uden netværkspolitikker kan hver pod kommunikere med hver anden pod - en kompromitteret webapplikationspod kan få direkte adgang til databasepoden, overvågningsstakken og Kubernetes API serveren. Standard-afvis-netværkspolitikker reducerer øjeblikkeligt eksplosionsradius for enhver containerkompromittering.
Skal jeg bruge et servicenet for sikkerhed?
Service mesh (Istio, Linkerd) tilføjer mTLS mellem tjenester, der giver kryptering og autentificering til al inter-pod kommunikation. Hvis du håndterer følsomme data eller har brug for at opfylde overholdelseskrav til kryptering under transport, er service mesh værdifuld. For enklere miljøer kan netværkspolitikker alene være tilstrækkelige.
Hvordan håndterer jeg hemmeligheder i Kubernetes sikkert?
Brug en ekstern hemmelighedsadministrator (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) med en Kubernetes hemmelighedsoperatør (External Secrets Operator, Vault Secrets Operator). Dette holder hemmeligheder ude af Git, giver revisionslogning, muliggør rotation og centraliserer hemmelig styring på tværs af Kubernetes og ikke-Kubernetes arbejdsbelastninger.