Vad är Pod Security Standards och hur skiljer det sig från Pod Security Policies?

Pod Security Standards (PSS) har ersatt Pod Security Policies (PSP) som är deprecated sedan K8s 1.21 och borttaget i 1.25. PSS har tre nivåer: Privileged, Baseline och Restricted. Implementeras via Pod Security Admission (PSA). PSP var en beta-funktion som var komplex och svår att använda – PSS/PSA är enklare och rekommenderas.

Vad är skillnaden mellan OPA/Gatekeeper och Kyverno?

OPA/Gatekeeper använder Rego-språket för policyer – kraftfullt men med brant inlärningskurva. Kyverno skriver policyer som YAML (Kubernetes-native) med match/exclude/validate/mutate – enklare att lära och använda. Kyverno har också förbyggda policy-sets. Välj Gatekeeper om du redan kan Rego, annars Kyverno.

Hur förhindrar jag att en angripare använder en komprometterad container för lateral rörelse?

Tre viktiga kontroller: (1) Network Policies med default-deny förhindrar containern från att nå andra pods. (2) RBAC med minimala service account-behörigheter förhindrar API-server-åtkomst. (3) Pod Security Standards på Restricted-nivå förhindrar privilege-eskalering och hostPath-volymmontering.

Vilka är de vanligaste K8s-säkerhetsmisstagen?

1) Container körs som root. 2) Inga resource limits på pods. 3) Överprivilegierade RBAC-roller (cluster-admin till default service account). 4) Inga Network Policies (all pod-to-pod-trafik tillåten). 5) Oaktiverad etcd-kryptering. 6) Långlivade service account-tokens. 7) Images från untrusted registries utan scanning. 8) Föråldrade K8s-versioner med kända CVE:er.

Vad är Falco och hur fungerar det?

Falco är ett CNCF-projekt för runtime-säkerhet som övervakar containers via system calls (eBPF eller Linux kernel module). Det upptäcker i realtid: shell i container, filändringar i känsliga kataloger, misstänkta nätverksanslutningar, och privilege-eskalering. Falco levereras med fördefinierade regler och stöder anpassade regler. Alerts skickas till SIEM, Slack, e-post eller stdout.

Kubernetes säkerhet: Skydda dina containerarbetslaster

Kubernetes-säkerhet är komplext men hanterbart med rätt verktyg och metoder. Denna guide täcker Pod Security Standards, RBAC, network policies, secrets management, image scanning, runtime security (Falco, OPA/Gatekeeper), admission controllers, service mesh security och CIS-benchmark.

Kubernetes (K8s) är den ledande containerorkestreraren 2026, men dess flexibilitet och komplexitet gör den också till ett attraktivt mål för angripare. En felkonfigurerad K8s-miljö kan exponera hela din applikationsstack – från containrar till databaser till moln-API:er. Enligt CNCF:s senaste säkerhetsrapport har 45% av organisationer upplevt en K8s-säkerhetsincident under det senaste året.

Den här guiden ger dig en komplett genomgång av K8s-säkerhet – från Pod Security Standards och RBAC till runtime-säkerhet med Falco och OPA/Gatekeeper. Jag har granskat och stärkt K8s-säkerheten för ett dussintal organisationer och delar här de viktigaste åtgärderna, rankade efter effekt.

Kubernetes säkerhetsmodell – lager-på-lager

K8s-säkerhet bygger på djupförsvar med flera lager: container-level (image scanning, runtime security), cluster-level (RBAC, Pod Security Standards, network policies), och platform-level (admission controllers, audit logging, CIS-benchmark). Varje lager måste vara korrekt konfigurerat – ett svagt lager kan kompromettera hela klustret.

En angripare som får tillgång till en container kan: använda containerns lokala resurser för lateral rörelse till andra pods, utnyttja överprivilegierade service accounts för att eskalera till kluster-admin, eller använda containerns nätverksåtkomst för att nå andra tjänster. Därför måste varje container ha minimala privilegier – både på K8s-nivå och på OS-nivå.

K8s säkerhetsmodell är delat ansvar: molnleverantören ansvarar för kluster-kontrollplanets säkerhet (API-server, etcd, controller-manager, scheduler) och node-säkerhet. Du som användare ansvarar för konfiguration av RBAC, Pod Security Standards, network policies, secrets och alla applikationssäkerhetsaspekter.

Pod Security Standards – skydda dina pods

Pod Security Standards (PSS) är en Kubernetes-native mekanism som definierar tre nivåer av containersäkerhet: Privileged (inga begränsningar – använd endast för systempods som nätverksagenter), Baseline (minimala begränsningar – förhindrar kända privilege-eskaleringar), och Restricted (strikta begränsningar – följer bästa praxis för produktion).

Använd Restricted-nivån för alla applikationspods i produktion. Restricted förhindrar: root-användare i containern, privilege-eskalering, hostPath-volymer, hostPort, hostNetwork, NET_RAW-capability, och ALL capabilities. Baseline tillåter de flesta applikationer men blockerar kända risker som hostPID, hostIPC och unsafe sysctls.

Pod Security Standards implementeras via Pod Security Admission (PSA) – en inbyggd admission controller som aktiverades som beta i K8s 1.23, stabil i 1.25. PSA evaluerar varje pod mot nivån som är konfigurerad för namespace (via labels). Använd verktyg som `psp-validator` för att testa dina pods mot PSS-regler innan du aktiverar dem i produktion.

RBAC – Role-Based Access Control i K8s

RBAC är den primära mekanismen för att kontrollera åtkomst i Kubernetes. RBAC definierar roller (vad som får göras på vilka resurser) och role bindings (vem som får rollen). Det finns två typer: Role/RoleBinding (namespace-scoped) och ClusterRole/ClusterRoleBinding (cluster-scoped). Följ least privilege – börja med minimalst möjliga roll och lägg till behörigheter efter behov.

Standard K8s-installationer har en ClusterRole "cluster-admin" som är bunden till system:serviceaccounts:kube-system:default. Detta är en säkerhetsrisk om en pod i kube-system komprometteras. Granska och ta bort överprivilegierade bindings. Använd kubectl commands som `kubectl describe clusterrolebinding –all | grep -A 10 cluster-admin` för att se vilka konton som har cluster-admin.

Skapa specifika roller för olika användare/tjänster: en roll för att läsa pods i ett namespace, en för att skapa deployments, en för att läsa secrets. Använd aggregate roles (K8s 1.19+) för att kombinera flera roller. Använd Kubescape eller kube-bench för att automatiskt granska RBAC-konfiguration mot best practices.

Network Policies – isolera dina arbetsbelastningar

Network Policies är en K8s-resurs som styr trafik mellan pods. Som standard är all pod-to-pod-trafik tillåten i Kubernetes (flat network). Network Policies låter dig definiera ingress- och egress-regler per pod baserat på labels, IP-block eller portar. Detta är en av de viktigaste säkerhetskontrollerna för att förhindra lateral rörelse efter en kompromettering.

Implementera en default-deny policy för varje namespace som blockerar all ingress- och egress-trafik. Skapa sedan specifika allow-policies för nödvändig trafik: frontend-pods får nå backend-pods på port 8080, backend-pods får nå databaser på port 5432. Använd label-selectors för att matcha pods – undvik IP-baserade regler eftersom pods kan ha dynamiska IP-adresser.

Network Policies kräver en CNI-plugin som stöder dem (Calico, Cilium, Weave, Antrea). Kontrollera att din CNI är korrekt konfigurerad och att policies tillämpas. Använd verktyg som `np-viewer` eller Ciliums `cilium connectivity test` för att verifiera att dina policies fungerar som avsett.

Secrets management – hantera känslig data

Kubernetes Secrets är en inbyggd resurs för att lagra känslig data (lösenord, API-nycklar, certifikat). Secrets lagras som base64-kodade (inte krypterade) i etcd som standard. Aktivera encryption at rest för etcd med KMS-plugin (AWS KMS, Azure Key Vault, GCP Cloud KMS, eller HashiCorp Vault). Detta är en kritisk inställning som många missar.

Använd externa secrets-verktyg i stället för att lagra känslig data direkt i Secrets-resurser: External Secrets Operator (synkroniserar från AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), Sealed Secrets (krypterar Secrets i Git), eller HashiCorp Vault (fullständig secrets-hantering med dynamiska credentials och rotation).

Bästa praxis: en secret per credential (inte en stor secret med allt), rotera secrets automatiskt (med Vault eller External Secrets Operator), begränsa RBAC-åtkomst till secrets (endast de pods som verkligen behöver dem), och undvik att logga secrets (använd verktyg som detect-secrets i CI/CD).

Image scanning och container-säkerhet

Container images är en av de största attackytorna. En image kan innehålla sårbara bibliotek, hemligheter, eller skadlig kod. Image scanning analyserar images mot kända sårbarhetsdatabaser (CVE, NVD) och identifierar risker. Integrera scanning i din CI/CD-pipeline – bygg steget måste passera scanning innan deploy.

Docker Scout, Trivy (Aqua), Snyk, och Grype är populära image scanning-verktyg. Trivy är open source och integreras enkelt i Dockerfile-byggen. För produktion: använd ett registry-level scanning-verktyg som AWS ECR scanning, Azure Container Registry scanning, eller GCP Artifact Registry scanning – de scannar automatiskt varje pushad image.

Använd distroless-basimages eller minimalistiska images (Alpine, scratch) för att minska attackytan. Undvik att köra containers som root – skapa en icke-root-användare i Dockerfile. Signera dina images med Docker Content Trust eller Cosign (Sigstore) för att garantera integritet och äkthet. Inför ImagePolicyWebhook i K8s för att endast tillåta signerade images i produktion.

Runtime-säkerhet med Falco och OPA/Gatekeeper

Runtime-säkerhet övervakar containerbeteende i realtid. Falco (CNCF-projekt) är standardverktyget för runtime-säkerhet i K8s. Falco använder system calls från Linux-kärnan (via eBPF eller kernel module) för att upptäcka avvikande beteenden: shell i container, filändringar i känsliga kataloger, nätverksanslutningar till misstänkta IP-adresser, eller privilege-eskalering.

Falco levereras med fördefinierade regler (Falco Rules) som täcker vanliga attackmönster: "Terminal shell in container", "Write below binary directory", "Unexpected outbound connection", och "Privileged container". Du kan skapa anpassade regler för din applikation – till exempel "alert om containern anropar en API-endpoint utanför sin tillåtna lista".

OPA/Gatekeeper (Open Policy Agent) är en admission controller som evaluerar alla K8s-resurser mot anpassade policyer före skapande eller uppdatering. Exempel på Gatekeeper-policyer: "alla containers måste ha resource limits", "inga images från untrusted registries", "alla deployments måste ha minst 3 repliker", "containers måste köras som icke-root". Gatekeeper är kraftfullare och mer flexibel än Pod Security Standards.

Admission Controllers – sista försvarslinjen

Admission controllers är K8s-komponenter som interceptar API-server requests efter autentisering och auktorisering men före persistence. De kan mutera (ändra) eller validera (godkänna/avvisa) requests. Inbyggda admission controllers: PodSecurity, NodeRestriction, AlwaysPullImages, DefaultStorageClass. Externa: OPA/Gatekeeper, Kyverno, KubeArmor.

Kyverno är ett alternativ till Gatekeeper som är lättare att använda – policyer skrivs som Kubernetes-resurser (YAML) i stället för Rego (OPA:s policy-språk). Kyverno har förbyggda policy-sets för Pod Security Standards, best practices, och compliance (CIS, NIST, PCI-DSS). För team utan OPA-erfarenhet är Kyverno ofta ett bättre val.

Aktivera AlwaysPullImages admission controller för att tvinga K8s att alltid hämta den senaste imagen från registry (förhindrar att en nod använder en gammal, sårbar image-cache). Använd NodeRestriction för att begränsa Kubelet-access. Aktivera audit logging för alla admission controllers för att ha spårbarhet av vilka policyer som tillämpades.

Service Mesh-säkerhet

Service mesh (Istio, Linkerd, Cilium) lägger till ett security-lager på service-to-service-kommunikation. En service mesh kan: kryptera all service-to-service-trafik (mTLS), implementera granular access control (vem får prata med vem), logga all trafik för granskning, och tillämpa retries/timeouts/circuit breaking.

Istio är den mest använda service meshen och har starka säkerhetsfunktioner: automatisk mTLS (krypterar all trafik mellan Istio-instrumenterade pods), AuthorizationPolicy (granular access control baserat på service accounts och namespaces), och PeerAuthentication (tvingar mTLS). Linkerd är enklare och lättare men har färre säkerhetsfunktioner.

Cilium är en CNI-plugin som också agerar service mesh (Cilium Service Mesh). Cilium använder eBPF för att implementera nätverkssäkerhet med hög prestanda – utan sidecar-proxy. Cilium stöder mTLS, network policies, och L7-protokollinspektion med lägre latens än Istio. För K8s-kluster med höga prestandakrav är Cilium ofta det bästa valet.

CIS Benchmark för Kubernetes

CIS (Center for Internet Security) Kubernetes Benchmark är en standard för säker konfiguration av K8s. Benchmark innehåller 100+ kontrollpunkter fördelade på kategorier: master node-säkerhet, worker node-säkerhet, etcd-säkerhet, kontrolplanskonfiguration, RBAC, pod-säkerhet, logging och nätverk.

kube-bench är ett open source-verktyg som automatiserar CIS Benchmark-granskning. Det körs som en pod (Job) i ditt kluster och rapporterar vilka kontrollpunkter som passerar och vilka som misslyckas. Kör kube-bench regelbundet – minst vid varje K8s-versionuppgradering och kvartalsvis. Åtgärda kritiska och höga avvikelser omedelbart.

Kubescape är ett annat verktyg från ARMO (CNCF-projekt) som kombinerar CIS Benchmark, NSA Kubernetes Hardening Guide och MITRE ATT&CK-ramverket. Kubescape kan köras både som CLI-verktyg och som admission controller. Det ger en riskpoäng per resurs och rekommendationer för att åtgärda sårbarheter.

Sammanfattning: K8s-säkerhetschecklista

Konfigurera Pod Security Standards på Restricted-nivå för alla produktions-namespaces.
Implementera RBAC med least privilege – inga onödiga ClusterRoleBindings.
Aktivera Network Policies med default-deny för varje namespace.
Kryptera etcd-data med KMS-plugin och använd externa secrets-verktyg (Vault, External Secrets Operator).
Scanna alla containerimages i CI/CD – blockera deploy om kritiska sårbarheter hittas.
Installera Falco för runtime-säkerhet – upptäck avvikande beteenden i realtid.
Implementera OPA/Gatekeeper eller Kyverno som admission controller.
Använd service mesh (Istio, Cilium) för mTLS och granular access control mellan tjänster.
Kör kube-bench eller Kubescape för CIS Benchmark-granskning kvartalsvis.
Aktivera audit logging för all API-server-trafik och övervaka med SIEM-verktyg.

Kubernetes-säkerhet är en resa, inte en destination. Börja med de mest kritiska kontrollerna (RBAC, Network Policies, Pod Security Standards) och bygg ut successivt. Varje lager du lägger till minskar risken för en lyckad attack.

Vill du ha hjälp med Kubernetes-säkerhet?

Jag hjälper organisationer att granska och stärka sin K8s-säkerhet. Läs mer om säkerhetstjänster eller boka ett samtal.