Kubernetes Container-sikkerhet: 12 Steg, 45 Min [2026]

Regelen bør være: én dedikert service-account per arbeidslast, aldri standardkontoen, og aldri bredere rettigheter enn appen faktisk bruker. Kjør kubectl auth can-i --list --as=system:serviceaccount:produksjon:betaling-app jevnlig for å verifisere at kontoen faktisk er begrenset som tiltenkt.

Vær også bevisst på forskjellen mellom Role og ClusterRole. En Role gjelder kun innenfor ett namespace, mens en ClusterRole gjelder på tvers av hele klyngen. Det er en vanlig feil å gripe til ClusterRole fordi det "bare fungerer" uten å tenke over namespace-grenser, når det appen egentlig trenger er tilgang begrenset til sitt eget namespace. Bruk ClusterRole kun når arbeidslasten faktisk må lese ressurser på tvers av flere namespaces, for eksempel en overvåkningsagent.

Steg 6: Håndhev Pod Security Admission med Restricted-profil

Pod Security Admission (PSA) er den offisielle etterfølgeren til det utfasede PodSecurityPolicy-mekanismen, og har vært tilgjengelig siden versjon 1.25. PSA er i dag den anbefalte standarden for å håndheve sikkerhetsprofiler på pod-nivå, med tre nivåer: Privileged, Baseline og Restricted.

# Merk et namespace med Restricted-profilen, håndhevet i praksis
kubectl label namespace produksjon \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

# Test at en usikker pod faktisk blir avvist
kubectl run test-privilegert --image=nginx \
  --overrides='{"spec":{"containers":[{"name":"test","image":"nginx","securityContext":{"privileged":true}}]}}' \
  -n produksjon

Hvis policyen er satt riktig opp, avviser klyngen forsøket med en feilmelding i stil med pods "test-privilegert" is forbidden: violates PodSecurity "restricted:latest": privileged (container "test" must not set securityContext.privileged=true). Bygg alle nye namespaces med denne merkingen fra dag én, det er langt vanskeligere å stramme inn etterpå enn å starte strengt.

Steg 7: Isoler pods med nettverkspolicyer og default-deny

Uten NetworkPolicy kan alle pods i en klynge som standard snakke med alle andre pods. Det betyr at en kompromittert frontend-pod fritt kan skanne og nå databaser, interne APIer og betalingstjenester. Løsningen er å starte med en default-deny-regel og deretter åpne opp bare den trafikken applikasjonene faktisk trenger.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-alt
  namespace: produksjon
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tillat-frontend-til-backend
  namespace: produksjon
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Husk at NetworkPolicy krever en CNI-plugin som faktisk håndhever reglene, for eksempel Calico eller Cilium. Kind bruker som standard kindnet, som ikke håndhever NetworkPolicy, så for å teste dette lokalt må du installere Calico på Kind-klyngen først.

Glem heller ikke egress-regler. De fleste team husker å begrense innkommende trafikk, men glemmer utgående. En kompromittert pod som fritt kan nå internett, kan fortsatt eksfiltrere data eller ringe hjem til en angriperkontrollert server selv om ingressen er strengt låst ned. Legg til en eksplisitt egress-regel som kun tillater DNS-oppslag og trafikk til kjente, nødvendige tjenester, og bygg videre derfra i stedet for å la egress stå åpent som standard.

Steg 8: Krypter hemmeligheter med KMS v2 og etcd-kryptering

Kubernetes Secrets lagres i etcd, og uten kryptering ligger de i klartekst på disk. KMS v2-provideren lar deg kryptere secrets med nøkler forvaltet av en ekstern nøkkeltjeneste, for eksempel AWS KMS, Azure Key Vault eller HashiCorp Vault, i stedet for å stole på lokal disk-kryptering alene.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - kms:
      apiVersion: v2
      name: ekstern-kms
      endpoint: unix:///var/run/kms-provider/socket.sock
      timeout: 3s
  - identity: {}

Legg denne konfigurasjonen til API-serverens --encryption-provider-config-flagg. Etter aktivering bør du rotere alle eksisterende secrets slik at de faktisk blir kryptert med den nye nøkkelen: kubectl get secrets --all-namespaces -o json | kubectl replace -f - tvinger en omskriving av alle secret-objekter gjennom det nye krypteringslaget.

Hvis du kjører på en administrert tjeneste som GKE, AKS eller EKS, tilbyr alle tre skyleverandørene KMS-integrasjon som en innebygd funksjon du kan slå på uten å konfigurere API-serveren manuelt. Sjekk dokumentasjonen for din spesifikke plattform, siden navnet på funksjonen og aktiveringsmåten varierer. Uansett hvilken vei du velger, er selve prinsippet det samme: nøklene som krypterer secrets skal aldri ligge lagret sammen med selve klyngen, de skal forvaltes av en separat tjeneste med eget tilgangskontrollregime.

Steg 9 og 10: Installer Falco og skriv egne runtime-regler

Falco er det CNCF-graduerte standardverktøyet for runtime-sikkerhet i containere. Det overvåker kernel-systemkall, i dag typisk via eBPF, og trigger regler som "shell spawned in container" eller "write below /etc". Der Trivy og Docker Scout stopper trusler før deploy, fanger Falco opp det som skjer etter at en container allerede kjører, inkludert forsøk på å utnytte sårbarheter som Fragnesia i sanntid.

# Installer Falco med Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf

# Se live-alarmer fra klyngen
kubectl logs -n falco -l app.kubernetes.io/name=falco -f

Eksempel på en Falco-alarm når noen åpner et skall inne i en container:

23:14:02.113881458: Notice A shell was spawned in a container
with an attached terminal (user=root user_loginuid=-1
container_id=8f3a2b1c9d4e container_name=betaling-app
shell=bash parent=runc cmdline=bash
image=produksjon/betaling-app:1.4.0)
priority=Notice rule=Terminal shell in container

Standardreglene dekker mye, men de mest verdifulle deteksjonene kommer ofte fra egne regler tilpasset applikasjonene dine:

- rule: Uventet utgående forbindelse fra betalingstjeneste
  desc: Varsler når betaling-app kobler til noe utenfor kjente IP-er
  condition: >
    outbound and container.image.repository = "produksjon/betaling-app"
    and not fd.sip in (kjente_betalings_endepunkter)
  output: >
    Uventet utgående trafikk fra betalingscontainer
    (command=%proc.cmdline connection=%fd.name)
  priority: WARNING

Koble Falco-alarmene til Slack, Teams eller din SIEM-løsning via Falcosidekick, slik at varsler faktisk når noen i sanntid i stedet for å forsvinne i logger ingen leser.

Vær forberedt på en periode med støy rett etter installasjon. Standardreglene i Falco er skrevet for å dekke generiske Linux-servere og containere, og vil i starten trigge på helt legitim atferd i applikasjonene dine, for eksempel et deploy-skript som midlertidig åpner et skall for helsesjekker. Sett av den første uken til å gå gjennom alarmene manuelt og enten justere reglene eller legge til unntak for kjent, forventet atferd. Et deteksjonssystem alle ignorerer fordi det roper ulv for ofte, er verdiløst uansett hvor teknisk avansert det er.

Steg 11 og 12: Patch Fragnesia-sårbarheten og automatiser audit-logging

Med kontrollene over på plass gjenstår det viktigste enkeltsteget: hold selve klyngen oppdatert. GKE sin bulletin om CVE-2026-46300 anbefaler å oppgradere nodegrupper til patchede versjoner, blant annet 1.36.0-gke.3545000, 1.35.6-gke.1039000 og 1.30.14-gke.2726000 for de som fortsatt henger igjen på eldre spor. Uansett hvilken skyleverandør du bruker, bør node-oppgradering behandles som en sikkerhetsoppgave med egen SLA, ikke en vedlikeholdsjobb som skyves ut.

# Sjekk hvilken versjon nodene dine kjører
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion

# Aktiver audit-logging på API-serveren (eksempel policy)
cat < audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "pods"]
- level: Metadata
  omitStages: ["RequestReceived"]
EOF

Legg --audit-policy-file=audit-policy.yaml og --audit-log-path til API-serverens oppstartsflagg. Send loggene videre til et sentralt SIEM-system, og sett opp en enkel dashboard som viser hvem som har opprettet pods de siste 24 timene. Det er nøyaktig den innsikten du trenger for raskt å se om noen utnytter en RBAC-svakhet som Fragnesia-relaterte pod-opprettelser.

Sett også opp et automatisk varsel som trigges hvis antall pod-opprettelser fra én enkelt bruker eller service-account plutselig hopper langt over normalen. Dette er et av de enkleste, men mest effektive signalene for å fange både feilkonfigurert automatisering og reelt misbruk tidlig, lenge før det får utvikle seg til et fullverdig innbrudd.

Kubernetes-versjoner og sikkerhetsstøtte i 2026

Hvilken versjon klyngen din kjører, avgjør om du i det hele tatt mottar sikkerhetsoppdateringer. Tabellen under viser status for versjonene som er relevante i 2026.

Andre administrerte Kubernetes-tjenester følger lignende løp. Alibaba sin ACK-tjeneste ga ut versjon 1.36 i mai 2026 med støtte frem til 30. mai 2027, noe som understreker mønsteret: produksjonsklynger i 2026 bør regnes som 1.34–1.36, ikke eldre versjoner du kanskje husker fra i fjor.

NIS2 og container-sikkerhet: hva EU-regelverket krever av nordiske virksomheter

For norske og nordiske virksomheter som driver samfunnskritisk infrastruktur eller tjenester av en viss størrelse, er container-sikkerhet ikke lenger bare et teknisk valg. NIS2-direktivet stiller eksplisitte krav til risikostyring i leverandørkjeden, håndtering av sårbarheter og hendelsesrapportering, og containeriserte arbeidslaster faller rett innenfor dette virkeområdet siden de ofte utgjør selve produksjonsmiljøet for kritiske tjenester. Norge har fulgt opp EU-direktivet gjennom nasjonal lovgivning som legger tilsvarende plikter på virksomheter innenfor definerte sektorer, blant dem energi, transport, helse og digital infrastruktur.

I praksis betyr det at flere av stegene i denne guiden ikke bare er god praksis, de er dokumentasjon du kan vise frem ved et tilsyn. Image-scanning med Trivy eller Docker Scout gir deg et revisjonsspor som viser at du faktisk sjekker for kjente sårbarheter før kode når produksjon. Audit-logging fra Steg 12 gir deg sporbarhet på hvem som gjorde hva og når, noe som er sentralt både for interne granskninger og for å oppfylle meldeplikten ved sikkerhetshendelser. RBAC-herding fra Steg 5 dokumenterer at du følger prinsippet om minste privilegium, som går igjen i de fleste rammeverk for informasjonssikkerhet virksomheter i Norden må forholde seg til.

Snakk med sikkerhetsansvarlig eller compliance-teamet ditt om hvilken kategori virksomheten din havner i under NIS2, og la den vurderingen styre hvor strengt du håndhever kontrollene i denne guiden. En liten SaaS-leverandør uten kritisk infrastruktur har mer handlingsrom enn en operatør av samfunnskritiske systemer, men begge har mye å tjene på et oppsett som allerede er dokumentert og revisjonsklart fra første dag.

Verktøysammenligning: Trivy, Docker Scout og Falco

De tre verktøyene i denne guiden dekker ikke det samme problemet, og du trenger som regel alle tre, ikke bare ett.

Trivy og Docker Scout stopper det du visste om på forhånd, altså kjente CVE-er. Falco fanger det du ikke visste om, som en angriper som utnytter en zero-day eller misbruker en legitim rettighet på en uventet måte. Kombinasjonen av bygge-tids skanning og runtime-deteksjon er det som gjerne kalles "shift left, watch right" i moderne container-sikkerhet.

Fem vanlige fallgruver du bør unngå

Selv team med gode intensjoner går ofte i de samme fellene når de setter opp container-sikkerhet for første gang. Ingen av disse er vanskelige å unngå når du vet om dem, men de er lette å overse midt i en travel utrulling.

• Å stole blindt på "latest"-tagger. Images tagget latest endrer seg under føttene dine. Bruk faste versjonstagger eller enda bedre, digest-referanser (@sha256:...), slik at du alltid vet nøyaktig hva som kjører.
• Å skanne images, men aldri revurdere dem. Et image som var rent i går kan ha en ny CVE i dag fordi en avhengighet fikk et nytt funn publisert. Sett opp periodisk re-skanning, ikke bare skanning ved bygg.
• Å bruke default service-account overalt. Det er raskt å komme i gang med, men gir hver kompromittert pod unødvendig bred tilgang til API-serveren.
• Å innføre NetworkPolicy uten å teste trafikkmønstre først. Default-deny uten forarbeid stopper ofte legitim trafikk mellom mikrotjenester du ikke visste var avhengige av hverandre.
• Å la Falco kjøre med kun standardregler. Standardreglene er en god start, men de kjenner ikke dine applikasjoners normale atferd, så du går glipp av mange relevante varsler uten egendefinerte regler.

Feilsøking: 8 vanlige problemer og løsninger

• Pods blir avvist av PodSecurity uten tydelig grunn. Kjør kubectl get events -n produksjon --field-selector reason=FailedCreate for å se den nøyaktige policy-bruddet i klartekst.
• NetworkPolicy ser riktig ut, men blokkerer ikke trafikk. Sjekk at CNI-pluginen din faktisk håndhever NetworkPolicy. Kindnet, flannel i standardoppsett og enkelte eldre CNI-er håndhever ikke reglene i det hele tatt.
• Falco starter ikke, eBPF-modulen feiler. Kontroller at nodens kjerneversjon støtter eBPF CO-RE. Eldre kjerner under 4.14 krever ofte kernel-module-driveren i stedet.
• Trivy-skanning tar for lang tid i CI. Bruk --cache-dir for å persistere sårbarhetsdatabasen mellom kjøringer i stedet for å laste den ned på nytt hver gang.
• Service-account med automountServiceAccountToken: false gjør at appen ikke får kontakt med API-serveren. Hvis appen faktisk trenger API-tilgang, monter token eksplisitt i pod-spesifikasjonen i stedet for på kontoen.
• Docker Scout gir "ikke autentisert"-feil i CI. Sørg for at CI-jobben kjører docker login og har riktig organisasjons-scope satt før docker scout-kommandoer kjøres.
• KMS-kryptering av secrets feiler ved API-server-restart. Bekreft at KMS-pluginens socket faktisk er tilgjengelig før API-serveren starter, en race condition her er en vanlig årsak til krasj ved oppstart.
• Audit-logger fylles opp disken raskt. Begrens policyen til kun de ressurstypene du faktisk trenger (som secrets og pods på RequestResponse-nivå), og send logger videre til ekstern lagring fremfor å beholde alt lokalt.

Avanserte tips for produksjonsmiljøer

Når grunnmuren fra de 12 stegene er på plass, er neste nivå å signere images med Sigstore/Cosign og håndheve at klyngen kun kjører signerte, verifiserte images via en admission-kontroller. Dette lukker et av de siste hullene i forsyningskjeden: selv om et image passerer Trivy- og Scout-skanning, vil du fortsatt vite at det faktisk kom fra din egen CI-pipeline og ikke ble byttet ut underveis.

Vurder også å generere en SBOM (Software Bill of Materials) for hvert image som en del av bygget, slik at du kan svare raskt neste gang en ny CVE i en populær avhengighet dukker opp, uten å måtte skanne alt på nytt for å finne ut hvilke systemer som er berørt. Kombiner dette med CIS Kubernetes Benchmark for å få en punktvis sjekkliste for kontrollplan-herding utover det som er dekket her, og kjør kube-bench periodisk for å måle avvik fra benchmarken automatisk.

Til slutt, bygg en enkel "game day"-øvelse der teamet ditt simulerer et container-utbrudd i et testmiljø og øver på å bruke Falco-alarmer, audit-logger og RBAC-begrensninger til å begrense skaden. Verktøyene i denne guiden er bare like gode som teamets evne til å reagere når de faktisk trigges.

Et annet grep som betaler seg over tid er å automatisere selve base-image-hygienen. Sett opp en jobb som flagger alle base-images eldre enn seks måneder og oppretter en pull request med oppdatert base-image automatisk, for eksempel med Renovate eller Dependabot konfigurert mot Dockerfile-er. Kombiner det med en fast rebuild-rytme, selv for images der ingen kodeendring har skjedd, siden nye sårbarheter i underliggende pakker dukker opp uavhengig av om du har endret egen kode. Mange team lener seg også mer og mer på minimale distribusjoner, som Distroless eller Alpine-baserte images, rett og slett fordi et mindre image har færre pakker som kan inneholde en fremtidig CVE.

Komplett eksempelprosjekt: fra image til overvåket klynge

Under følger et minimalt, men komplett oppsett som binder sammen alle 12 stegene i én arbeidsflyt du kan kopiere direkte inn i et testprosjekt.

# 1. Bygg og skann image
docker build -t registry.local/betaling-app:1.4.0 .
trivy image --severity HIGH,CRITICAL --exit-code 1 registry.local/betaling-app:1.4.0
docker scout cves registry.local/betaling-app:1.4.0 --only-severity critical --exit-code

# 2. Push kun hvis skanning er grønn
docker push registry.local/betaling-app:1.4.0

# 3. Opprett namespace med Restricted PSA
kubectl create namespace produksjon
kubectl label namespace produksjon pod-security.kubernetes.io/enforce=restricted

# 4. Dedikert service-account med minimal RBAC
kubectl create serviceaccount betaling-app -n produksjon
kubectl apply -f rbac-betaling-app.yaml

# 5. Deploy med default-deny NetworkPolicy allerede aktiv
kubectl apply -f network-policy.yaml
kubectl apply -f deployment-betaling-app.yaml

# 6. Verifiser at Falco overvåker namespacet
kubectl logs -n falco -l app.kubernetes.io/name=falco --since=5m | grep produksjon

Med dette oppsettet kjørende har du et image som er skannet før push, en klynge som håndhever restriktive pod-policyer, en applikasjon som kjører med minimale rettigheter, nettverkstrafikk som er eksplisitt tillatt fremfor implisitt åpen, og runtime-overvåkning som varsler deg hvis noe likevel går galt. Det er nøyaktig de fire C-ene i praksis, ikke bare i teorien.

Tabellen under oppsummerer hvilket verktøy som hører til hvert av de 12 stegene, slik at du har en rask referanse å sjekke oppsettet ditt mot.

Ofte stilte spørsmål

Trenger jeg både Trivy og Docker Scout, eller holder det med ett verktøy?

De fleste team klarer seg fint med ett skanneverktøy i CI, forutsatt at de faktisk bruker det konsekvent. Trivy er det mest brukte gratis alternativet og dekker både images og klyngeressurser, mens Docker Scout gir bedre risikoscoring og policy-gating hvis du allerede bruker Docker sitt økosystem. Å kjøre begge parallelt gir marginalt bedre dekning, men den største gevinsten kommer fra å faktisk håndheve terskler, ikke fra hvilket verktøy du velger.

Er Falco nødvendig hvis jeg allerede har et kommersielt sikkerhetsverktøy?

Ikke nødvendigvis. Mange kommersielle plattformer bygger faktisk på samme eBPF-telemetri som Falco bruker under panseret. Poenget er at du har en eller annen form for runtime-deteksjon, ikke spesifikt Falco. Fordelen med Falco er at det er CNCF-graduert, gratis, og gir deg full kontroll over reglene uten leverandørbinding.

Hvor ofte bør jeg oppgradere Kubernetes-versjon?

Følg gjerne skyleverandørens støttevindu, men som en tommelfingerregel bør du aldri kjøre en versjon som er mer enn to minor-versjoner bak siste stabile utgivelse. Med 1.30 nå utfaset og 1.34–1.36 som aktiv standard i 2026, betyr det i praksis en oppgradering hver tredje til fjerde måned for de fleste produksjonsklynger. Sett opp en fast rutine for dette fremfor å vente til en sårbarhet tvinger deg til det, siden en planlagt oppgradering nesten alltid er billigere og mindre stressende enn en hastepatch under tidspress.

Hva gjør jeg hvis jeg ikke kan patche mot Fragnesia-sårbarheten med en gang?

Google sin egen anbefaling er å begrense hvem som kan opprette pods i klyngen inntil node-oppgraderingen er fullført, siden det er hovedveien inn for å utnytte svakheten. Kombiner det med økt overvåkning via Falco på noder som ennå ikke er patchet, slik at du i det minste ser forsøk på utnyttelse i sanntid.

Kan jeg bruke Pod Security Admission og en tredjeparts admission-kontroller samtidig?

Ja, og det er faktisk en vanlig kombinasjon. PSA håndhever grunnleggende pod-sikkerhetsprofiler direkte innebygd i Kubernetes, mens et verktøy som OPA Gatekeeper eller Kyverno kan håndheve mer detaljerte, organisasjonsspesifikke policyer på toppen, for eksempel krav om signerte images eller obligatoriske ressursgrenser.

Påvirker NetworkPolicy ytelsen i klyngen?

Overheaden er normalt minimal med moderne eBPF-baserte CNI-er som Cilium. Med eldre iptables-baserte implementasjoner kan et svært høyt antall regler i store klynger gi merkbar latens, så test alltid ytelsen med et representativt antall policyer før du ruller ut i stor skala.

Må jeg kryptere alle secrets, eller holder det med de mest sensitive?

Krypter alle secrets som standard. Kostnaden ved å aktivere KMS v2-kryptering for hele klyngen er lav, mens kostnaden ved å glemme ett enkelt sensitivt secret fordi det ikke sto på en manuelt vedlikeholdt liste kan være svært høy.

Hvor lang tid tar det å implementere alle 12 stegene i en eksisterende klynge?

Selve verktøyinstallasjonen tar om lag 45 minutter, som denne guiden er bygget rundt. Å faktisk migrere en eksisterende produksjonsklynge til restriktiv RBAC, default-deny NetworkPolicy og håndhevet PSA uten å bryte noe tar normalt flere uker, siden du må kartlegge eksisterende trafikkmønstre og rettighetsbehov gradvis, namespace for namespace.

Relaterte saker

• Azure AKS-Sårbarhet: CVSS 9,4, 415 Feil Patchet [2026]
• OpenCost Setup: 12 Steg, 30% Lavere Skykostnad [2026]
• AWS FinOps-agent: 29% av Skyforbruket Kastes Bort [2026]
• Skyrepatriering: Norge 19 %, Finland Kutter 29 % [2026]
• AWS 76 %, Azure 74 %: Skysuverenitet Snur Norden [2026]

For flere saker om skyinfrastruktur og sikkerhet, se vår samleside for skytjenester.

Kilder og videre lesning: Kubernetes sin offisielle sikkerhetsdokumentasjon, Pod Security Standards, OWASP Kubernetes Top 10, Falco-dokumentasjonen, Trivy, Docker Scout, og Google Kubernetes Engine sine sikkerhetsbulletiner.