Förberedelser: scope, miljö och regler

Innan ett enda kommando körs måste scope och förutsättningar vara kristallklara. Kubernetes-pentest utan tydligt scope är en recept för driftincidenter.

Definiera testomfattning

Speglad miljö vs. produktion

Vår starka rekommendation: testa mot en speglad staging-miljö som replikerar produktionskonfigurationen. Med Terraform eller annan IaC kan ni spinna upp en identisk klusterkopia snabbt. Det eliminerar risken för produktionsavbrott under testningen.

Om produktion måste testas direkt — exempelvis för att verifiera nätverkssegmentering som bara finns där — krävs en dokumenterad incidentplan, rollback-procedurer och realtidsövervakning via NOC.

Juridiska förutsättningar

Penetrationstestning utan skriftligt avtal är olagligt, oavsett intention. Säkerställ:

• Skriftligt godkännande från systemägare (inte bara IT-avdelningen)
• Molnleverantörens regler — AWS tillåter pentest utan förhandsgodkännande för de flesta tjänster sedan 2024, men Azure och GCP har specifika villkor
• NIS2-regelefterlevnad — dokumentera att testet ingår i er regelbundna säkerhetsverifiering

Managerade molntjänster

Steg 1: Rekognosering och informationsinhämtning

Rekognoseringsfasen kartlägger klustrets exponerade yta innan aktiva tester inleds.

Extern rekognosering

Från ett externt perspektiv (black-box) börjar arbetet med att identifiera vad som är exponerat mot internet:

```bash

Identifiera exponerade Kubernetes API-servrar

nmap -sV -p 6443,8443,10250,10255,2379

Sök efter exponerade dashboards

kubectl proxy & curl http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services

```

Vanliga fynd i denna fas:

• Kubernetes Dashboard exponerat utan autentisering
• Kubelet API (port 10250) öppet för anonyma anrop
• etcd (port 2379) tillgängligt utan klient-TLS

Intern rekognosering (grey/white-box)

Med begränsad åtkomst — exempelvis en service account med minimal RBAC — kartläggs klustrets interna struktur:

```bash

Kartlägg tillgängliga API-resurser

kubectl api-resources --verbs=list -o name

Identifiera namespace och pods

kubectl get namespaces

kubectl get pods --all-namespaces

Granska din egen service accounts rättigheter

kubectl auth can-i --list

```

Verktygsbaserad skanning

Kör kube-hunter i klustret för att identifiera kända attackvektorer:

```bash

Kube-hunter i pod-läge

kubectl run kube-hunter --image=aquasec/kube-hunter --restart=Never -- --pod

```

Kube-bench mot CIS Kubernetes Benchmark:

```bash

CIS-benchmark granskning

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

kubectl logs job/kube-bench

```

Opsio-perspektiv: Vi ser ofta att kube-bench-rapporter ignoreras eftersom de genererar hundratals findings. Prioritera enligt: etcd-kryptering > RBAC-konfiguration > kubelet-autentisering > nätverkspolicyer. Det är den ordning angripare utnyttjar brister i.

Steg 2: RBAC-granskning — den kritiska ytan

Role-Based Access Control är det vanligaste området för kritiska brister. Det beror på att RBAC-policyer är komplexa, svåra att överblicka och sällan granskas efter initial uppsättning.

Vanliga RBAC-brister

Manuell RBAC-testning

```bash

Lista alla ClusterRoleBindings

kubectl get clusterrolebindings -o json | jq '.items[] | {name: .metadata.name, role: .roleRef.name, subjects: .subjects}'

Identifiera service accounts med cluster-admin

kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

Testa eskalering från en begränsad service account

kubectl auth can-i create pods --as=system:serviceaccount:default:default

kubectl auth can-i get secrets --as=system:serviceaccount:default:default

```

Verktyg: kubeaudit och rakkess

```bash

kubeaudit för övergripande RBAC-granskning

kubeaudit rbac

rakkess för visualisering av åtkomsträttigheter

kubectl access-matrix --as=system:serviceaccount:app-namespace:app-sa

```

Vad vi ser i produktion: I ungefär hälften av de kluster vi granskar har minst en service account rättigheter som möjliggör lateral movement till andra namespace. Det här är sällan avsiktligt — det är resultatet av att någon kopierade en YAML-fil från Stack Overflow 2023 och aldrig stramade åt den.

Steg 3: Nätverkssegmentering och policygranskning

Kubernetes har ingen nätverkssegmentering som standard. Utan NetworkPolicies kan varje pod kommunicera med varje annan pod i klustret — inklusive system-poddar i kube-system.

Testa nätverkssegmentering

```bash

Deploiera en testpod och verifiera nätverksåtkomst

kubectl run nettest --image=nicolaka/netshoot --restart=Never -- sleep 3600

Testa kommunikation mot andra namespace

kubectl exec nettest -- curl -s http://service-name.other-namespace.svc.cluster.local:8080

Testa åtkomst mot Kubernetes API-servern

kubectl exec nettest -- curl -sk https://kubernetes.default.svc/api/v1/namespaces

Testa åtkomst mot cloud metadata (IMDS)

kubectl exec nettest -- curl -s http://169.254.169.254/latest/meta-data/

```

Det sista kommandot är kritiskt. Om cloud metadata-tjänsten (IMDS) är åtkomlig från poddar kan en angripare hämta IAM-credentials för den underliggande noden — och därifrån eskalera till molnkontot.

Granska befintliga NetworkPolicies

```bash

Lista NetworkPolicies per namespace

kubectl get networkpolicies --all-namespaces

Analysera en specifik policy

kubectl describe networkpolicy -n

```

Rekommendation: Implementera en default-deny ingress-policy i varje namespace och öppna explicit. Det är det enda sättet att uppnå verklig mikrosegmentering:

```yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: default-deny-all

namespace: app-namespace

spec:

podSelector: {}

policyTypes:

- Ingress

- Egress

```

Managerad DevOps

Steg 4: Pod-säkerhet och container escape

Pod Security Standards (PSS) ersatte PodSecurityPolicies från Kubernetes 1.25. Kontrollera vilken enforce-nivå som gäller per namespace.

Testa privilegierade poddar

```bash

Försök skapa en privilegierad pod

kubectl apply -f - <

apiVersion: v1

kind: Pod

metadata:

name: priv-test

namespace: default

spec:

containers:

- name: priv

image: ubuntu

securityContext:

privileged: true

command: ["sleep", "3600"]

EOF

```

Om podden startar utan att blockeras av en admission controller saknar klustret grundläggande skydd mot container escape.

Container escape-tekniker att testa

```bash

Från en privilegierad pod — eskalera till nod

nsenter --target 1 --mount --uts --ipc --net --pid -- bash

Från en pod med hostPath: /

cat /host/etc/shadow

```

Secrets-hantering

```bash

Lista alla secrets i ett namespace

kubectl get secrets -n

Dekoda en secret

kubectl get secret -n -o jsonpath='{.data}' | base64 -d

```

Kubernetes secrets är base64-kodade, inte krypterade. Utan etcd-kryptering at rest är de i praktiken klartext. Vi rekommenderar externa lösningar som HashiCorp Vault, AWS Secrets Manager eller Azure Key Vault med CSI-driver.

Steg 5: Rapportering och åtgärder

En penetrationstestrapport som bara listar CVE-nummer är värdelös. Rapporten ska möjliggöra handling.

Rapportstruktur

1. Sammanfattning för ledning — risknivå, affärspåverkan, topp 3 åtgärder

2. Detaljerade fynd — varje sårbarhet med:

- Beskrivning och bevis (screenshots, kommandon)

- Riskvärdering (CVSS eller intern skala)

- Exploaterbarhet i er specifika miljö

- Konkret åtgärdsrekommendation med konfigurationsexempel

3. Attackkedjor — visa hur enskilda brister kombineras till fullständiga kompromissvägar

4. Prioriterad åtgärdslista — ordnad efter risk × exploaterbarhet

Vanliga åtgärder efter pentest

Regelefterlevnad och Kubernetes-pentest

För svenska organisationer som omfattas av NIS2-direktivet är regelbunden penetrationstestning inte frivillig — det är ett krav för att visa att tekniska säkerhetsåtgärder verifieras. ISO/IEC 27001 (Annex A.8.8) ställer liknande krav på teknisk sårbarhetsbedömning.

GDPR artikel 32 kräver "regelbunden testning, bedömning och utvärdering av effektiviteten hos tekniska och organisatoriska åtgärder". Ett Kubernetes-kluster som behandlar personuppgifter utan dokumenterad säkerhetsverifiering är en tydlig regelefterlevnadsrisk.

Integritetsskyddsmyndigheten (IMY) har i flera tillsynsbeslut lyft fram brister i teknisk säkerhetstestning som en grund för sanktionsavgifter. Att kunna visa en penetrationstestrapport och dokumenterade åtgärder är ett konkret skydd vid tillsyn.

Cloud FinOps

Verktygsöversikt

Opsios perspektiv: vad vi faktiskt ser

Från vårt SOC/NOC i Karlstad och Bangalore hanterar vi Kubernetes-miljöer dygnet runt. De tre vanligaste allvarliga fynden i penetrationstester:

1. RBAC-sprawl — rättigheter som ackumulerats över tid utan att gamla bindings tas bort. Lösning: kvartalsvis RBAC-granskning med rakkess-visualisering.

2. Avsaknad av nätverkspolicyer — hela klustret är ett platt nätverk. En komprometterad pod ger tillgång till allt. Lösning: default-deny med Calico eller Cilium.

3. IMDS-åtkomst från poddar — speciellt på EKS utan IMDSv2 enforced och utan pod-level IAM (IRSA). Det här är den snabbaste vägen från pod till molnkonto.

Kubernetes-säkerhet är inte ett engångsprojekt. Det är en kontinuerlig process som kräver teknisk djupkompetens och operationell vaksamhet — precis den kombination vi levererar.

Molnmigrering

Vanliga frågor

Hur ofta bör man pentesta ett Kubernetes-kluster?

Minst en gång per kvartal för produktionsmiljöer med externa tjänster, och alltid efter större infrastrukturändringar som klusteruppgraderingar, nya namespace-strukturer eller ändrade nätverkspolicyer. NIS2-direktivet kräver regelbunden verifiering av säkerhetsåtgärder för verksamheter som klassas som väsentliga.

Kan man pentesta Kubernetes i produktion?

Det är möjligt men kräver extremt strikt scope och en incidentplan. Vi rekommenderar i regel en speglad staging-miljö som replikerar produktionskonfigurationen. Testar du direkt mot produktion riskerar du avbrott i affärskritiska tjänster — och det är sällan värt risken.

Vilka verktyg behövs för Kubernetes-pentest?

Grunduppsättningen inkluderar kube-bench (CIS-benchmark), kube-hunter (klusterrekognosering), kubeaudit (konfigurationsgranskning) och kubectl med manuella tekniker. För nätverksanalys används Cilium eller Calico-policygranskning. Inget enskilt verktyg ger full täckning — kombinationen är avgörande.

Vad kostar ett Kubernetes-pentest?

Kostnaden varierar kraftigt beroende på klustrets komplexitet, antal namespace och om testet inkluderar applikationslagret. Räkna med 80 000–250 000 SEK för ett grundligt test av ett medelstort produktionskluster. Investeringen är liten jämfört med kostnaden för ett dataintrång.

Räcker det med automatiserade skanningar istället för manuellt pentest?

Nej. Automatiserade verktyg hittar kända felkonfigurationer men missar logiska brister, kedjade attackvägar och kontextberoende sårbarheter. En skanning kan rapportera att RBAC finns konfigurerat — men inte att en specifik ClusterRole ger lateral movement till etcd. Manuell expertis kompletterar verktygen.