Er Kubernetes-klyngen din sikker, eller kjører den bare?Standard Kubernetes-konfigurasjoner prioriterer brukervennlighet fremfor sikkerhet. Uten bevisst herding er klynger sårbare for rømming av beholdere, rettighetseskalering, sideveis bevegelse og datatyveri. Denne sjekklisten dekker hver sikkerhetskontroll du trenger for å implementere for produksjon Kubernetes miljøer.
Viktige takeaways
- Standard Kubernetes er ikke sikker:Ut-av-boksen-konfigurasjoner tillater privilegerte beholdere, ubegrenset nettverkstilgang og brede API-servertillatelser.
- RBAC er ditt første forsvar:Begrens API servertilgang til minimumskravet for hver tjenestekonto og bruker.
- Nettverkspolitikk forhindrer sideveis bevegelse:Uten nettverkspolicyer kan hver pod kommunisere med annenhver pod – et flatt nettverk inne i klyngen din.
- Pod-sikkerhetsstandarder erstatter PSP:Pod Security Admission (PSA) håndhever sikkerhetsbegrensninger på alle pods.
- Sikkerhet i forsyningskjeden:Bekreft bildets herkomst, søk etter sårbarheter og håndhev bildepolicyer gjennom adgangskontroll.
Kubernetes Sikkerhetssjekkliste
API Serversikkerhet
- Aktiver RBAC og deaktiver anonym autentisering
- Bruk sterk autentisering (OIDC, sertifikatbasert) — ikke grunnleggende autentisering eller statiske tokens
- Begrens API servertilgang til kjente IP-områder (administrert Kubernetes: bruk autoriserte nettverk)
- Aktiver revisjonslogging for alle API serverforespørsler
- Deaktiver alfa/beta-funksjoner i produksjonsklynger
- Konfigurer adgangskontrollere: PodSecurity, ResourceQuota, LimitRange
RBACs beste praksis
- Følg minste privilegium: ingen ClusterAdmin-bindinger for tjenestekontoer
- Bruk navnedelte roller i stedet for ClusterRoles der det er mulig
- Revider RBAC regelmessig med verktøy som kubectl-who-can og rbac-lookup
- Gi aldri jokertegntillatelser (verb: ["*"], ressurser: ["*"])
- Begrens tilgang til hemmeligheter – gi kun få/liste over hemmeligheter til pods som trenger dem
- Bruk separate tjenestekontoer per applikasjon (ikke standard tjenestekonto)
Nettverkssikkerhet
- Implementer standard-deny NetworkPolicies i alle navneområder
- Tillat bare nødvendig inn- og utgående trafikk per applikasjon
- Bruk en CNI som støtter NetworkPolicies (Calico, Cilium, Antrea)
- Krypter inter-pod-kommunikasjon med service mesh mTLS (Istio, Linkerd)
- Begrens utgang til kjente eksterne endepunkter (hindrer dataeksfiltrering)
- Isoler sensitive arbeidsbelastninger i dedikerte navneområder med strenge retningslinjer
Pod Security
- Aktiver Pod Security Admission på navneområdenivå (håndhev "begrenset" profil)
- Kjør beholdere som ikke-root (runAsNonRoot: true)
- Bruk skrivebeskyttet rotfilsystem (readOnlyRootFilesystem: true)
- Slipp alle muligheter, legg bare til det som trengs (slipp: ["ALL")
- Deaktiver rettighetseskalering (allowPrivilegeEscalation: false)
- Angi ressursgrenser (CPU, minne) på alle beholdere for å forhindre ressursmisbruk
- Ikke monter tjenestekontotokenet med mindre det er nødvendig (automountServiceAccountToken: false)
Bildesikkerhet
- Skann alle bilder for sårbarheter før distribusjon (Trivy, Snyk)
- Bruk minimalt med basisbilder (distroless, Alpine) for å redusere angrepsoverflaten
- Signer containerbilder og verifiser signaturer ved opptak (cosign, Notation)
- Tillat kun bilder fra klarerte registre (håndheves gjennom adgangskontroll)
- Bruk aldri :lastest tag — fest til spesifikke bildesammendrag for reproduserbarhet
- Gjenoppbygg og oppdater basebilder regelmessig for å inkludere sikkerhetsoppdateringer
Secrets Management
- Ikke lagre hemmeligheter i miljøvariabler eller ConfigMaps
- Bruk ekstern hemmelig administrasjon (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Hvis du bruker Kubernetes Secrets, aktiver kryptering i hvile (EncryptionConfiguration)
- Roter hemmeligheter regelmessig med automatisert rotasjon gjennom eksterne hemmelige operatører
- Begrens RBAC-tilgang til hemmeligheter – de fleste pods skal ikke kunne liste alle hemmeligheter
Overvåking og deteksjon
- Aktiver Kubernetes revisjonslogging og videresend til SIEM
- Distribuer kjøretidssikkerhetsovervåking (Falco, Sysdig)
- Overvåk for: uventet prosesskjøring, nettverkstilkoblinger, filendringer, rettighetseskalering
- Varsel om: ny ClusterRoleBinding-opprettelse, hemmelig tilgang av uventede pods, container exec-kommandoer
- Implementer brudd på Pod Security Policy som SIEM-varsler
CIS Kubernetes Benchmark
Center for Internet Security (CIS) publiserer detaljerte sikkerhetsstandarder for Kubernetes. Bruk kube-bench for automatisk å evaluere klyngen din mot CIS-benchmarks. Ta tak i alle kritiske og høye funn før produksjonsdistribusjon. Administrerte Kubernetes-tjenester (EKS, AKS, GKE) håndterer enkelte benchmark-elementer automatisk, men kundeansvarlige elementer krever fortsatt konfigurasjon.
Hvordan Opsio sikrer Kubernetes
- Klyngesikkerhetsvurdering:Vi evaluerer Kubernetes-klyngene dine i forhold til CIS-standarder og beste praksis for nettskyleverandører.
- Herdingsimplementering:Vi implementerer alle sjekklisteelementer, inkludert RBAC, nettverkspolicyer, podsikkerhet og overvåking.
- Kjøretidsovervåking:Våre SOC overvåker Kubernetes-klynger for sikkerhetshendelser og unormal oppførsel.
- Håndhevelse av retningslinjer:Vi distribuerer OPA/Gatekeeper eller Kyverno for å håndheve sikkerhetspolicyer automatisk.
- Pågående ledelse:Regelmessige sikkerhetsgjennomganger, CIS-benchmark-revurdering og sikkerhetskonfigurasjonsoppdateringer.
Ofte stilte spørsmål
Hva er den viktigste Kubernetes sikkerhetskontrollen?
Nettverkspolicyer med standard-nekt. Uten nettverkspolicyer kan hver pod kommunisere med annenhver pod - en kompromittert nettapplikasjonspod kan få direkte tilgang til databasepoden, overvåkingsstakken og Kubernetes API serveren. Standard-nekt-nettverkspolicyer reduserer umiddelbart eksplosjonsradiusen for ethvert containerkompromittering.
Bør jeg bruke et servicenettverk for sikkerhet?
Service mesh (Istio, Linkerd) legger til mTLS mellom tjenester, og gir kryptering og autentisering for all inter-pod-kommunikasjon. Hvis du håndterer sensitive data eller trenger å oppfylle samsvarskravene for kryptering under overføring, er tjenestenettverket verdifullt. For enklere miljøer kan nettverkspolicyer alene være tilstrekkelig.
Hvordan håndterer jeg hemmeligheter i Kubernetes sikkert?
Bruk en ekstern hemmelighetsadministrator (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) med en Kubernetes hemmelighetsoperatør (External Secrets Operator, Vault Secrets Operator). Dette holder hemmeligheter ute av Git, gir revisjonslogging, muliggjør rotasjon og sentraliserer hemmelig administrasjon på tvers av Kubernetes og ikke-Kubernetes arbeidsbelastninger.