Den grundläggande säkerhetsbaslinjen

Innan du investerar i avancerade verktyg behöver grunden vara på plats. Vi ser regelbundet i Opsios SOC att organisationer hoppar direkt till service mesh och zero-trust utan att ens ha grundläggande RBAC konfigurerat korrekt.

RBAC: principen om minsta privilegium

Role-Based Access Control (RBAC) styr vem och vad som får göra vad i klustret. Standardkonfigurationen i många installationer är alltför generös.

Konkreta åtgärder:

• Undvik cluster-admin för allt utom break-glass-scenarier
• Skapa namespace-specifika roller med explicita verb (get, list, watch) istället för wildcards
• Granska regelbundet vilka ServiceAccounts som har ClusterRoleBindings — det är vanligt att CI/CD-pipelines fått bredare rättigheter än nödvändigt under felsökning och aldrig stramats åt
• Använd kubectl auth can-i --list för att audita faktiska behörigheter

```yaml

Exempel: restriktiv roll för en applikations ServiceAccount

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: produktion

name: app-reader

rules:

• apiGroups: [""]

resources: ["pods", "services", "configmaps"]

verbs: ["get", "list", "watch"]

```

Nätverkspolicyer: stäng öst-väst-trafiken

Kubernetes tillåter som standard all trafik mellan poddar. Det första steget är att införa en deny-all-policy per namespace och sedan explicit öppna nödvändig kommunikation.

```yaml

Deny-all ingress i ett namespace

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: default-deny-ingress

namespace: produktion

spec:

podSelector: {}

policyTypes:

- Ingress

```

Viktigt: Nätverkspolicyer kräver en CNI-plugin som stödjer dem. Calico, Cilium och Antrea fungerar. Flannel i standardkonfiguration gör det inte — policyerna skapas utan felmeddelande men har noll effekt. Vi har sett organisationer som trott sig vara skyddade i månader med Flannel-kluster.

Pod Security Standards (PSS)

PSS ersatte det föråldrade PodSecurityPolicy och är inbyggt i Kubernetes sedan version 1.25. Tre nivåer definieras:

Enforcea Baseline som minimum på alla namespaces och Restricted för arbetsbelastningar som hanterar personuppgifter eller andra känsliga data. Under NIS2-direktivet, som trädde i kraft i oktober 2024, förväntas organisationer inom väsentliga sektorer kunna visa att de har tekniska åtgärder för att begränsa laterala rörelser — PSS i Restricted-läge är ett konkret sätt att demonstrera detta.

Molnsäkerhet

Säkerhet i bygg-pipeline: skifta vänster

De billigaste sårbarheterna att åtgärda är de som aldrig når produktion. Image-scanning och policy-validering i CI/CD är inte valfria.

Image-scanning och basimage-hygien

• Scanna images med verktyg som Trivy, Grype eller Snyk i varje pipeline-steg
• Använd minimala basimages: distroless, Alpine eller scratch-builds minskar attackytan dramatiskt
• Fixera image-taggar med digest (sha256:abc123...) istället för :latest — annars vet du inte vad som faktiskt körs
• Signera images med Cosign (från Sigstore-projektet) och verifiera signaturer vid deploy med en admission controller

Policy-as-code med OPA/Gatekeeper eller Kyverno

Admission controllers som validerar resurser innan de skapas i klustret är det effektivaste sättet att förhindra felkonfigurationer. Två dominerande alternativ:

Vår rekommendation: Kyverno om teamet primärt arbetar i Kubernetes och vill snabb time-to-value. Gatekeeper om ni redan har investerat i Rego-policyer eller behöver policyer över flera system.

Exempel på en Kyverno-policy som kräver att alla containrar har resource limits:

```yaml

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

name: require-resource-limits

spec:

validationFailureAction: Enforce

rules:

- name: check-limits

match:

any:

- resources:

kinds:

- Pod

validate:

message: "Alla containrar måste ha CPU och minnes-limits definierade."

pattern:

spec:

containers:

- resources:

limits:

memory: "?*"

cpu: "?*"

```

Managerad DevOps

Runtime-skydd: vad statisk analys missar

Scanning i pipeline fångar kända sårbarheter. Det fångar inte zero-days, komprometterade beroenden som aktiveras vid runtime eller laterala rörelser efter initial åtkomst. Runtime-skydd är det sista försvarslagret.

Falco och eBPF-baserad observabilitet

Falco (CNCF incubating project) övervakar systemanrop i realtid och larmar vid avvikande beteende: en container som plötsligt spawnar ett shell, skriver till /etc/shadow eller öppnar oväntade nätverksanslutningar.

Modernare alternativ som Tetragon (från Cilium-projektet) använder eBPF direkt för att observera och blockera — inte bara larma — utan extra overhead från kernel-moduler.

Vad vi ser i Opsios NOC: De vanligaste runtime-larmerna i Kubernetes handlar om:

1. Containrar som kör som root trots att det inte behövs

2. Oväntade utgående anslutningar (ofta komprometterade npm/pip-paket som ringer hem)

3. Exec-sessioner till produktionscontainrar som borde vara immutable

Loggning och audit trail

Kubernetes Audit Logging ska vara aktiverat på API-servern och skickas till ett centralt loggsystem (Elasticsearch, Loki, SIEM). Utan audit logs saknar ni förmåga att utreda incidenter — och det är ett krav under både ISO/IEC 27001 och NIS2.

Logga minst:

• Alla create, update, delete på klusterresurser
• Alla exec-kommandon till poddar
• Alla autentiseringsförsök (lyckade och misslyckade)
• Ändringar i RBAC-konfiguration

Secrets-hantering: sluta base64-koda hemligheter

Kubernetes Secrets lagrar data base64-kodat — inte krypterat. Vem som helst med läsrättigheter till secrets i ett namespace kan dekoda dem. Det är inte en säkerhetslösning, det är en bekvämlighetsabstraktion.

Bättre alternativ:

1. External Secrets Operator (ESO) — synkar hemligheter från externa valv (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) till Kubernetes Secrets vid runtime

2. Sealed Secrets — krypterar secrets så att de kan lagras i Git (GitOps-vänligt) och bara dekrypteras inne i klustret

3. CSI Secrets Store Driver — monterar hemligheter direkt som volymer utan att skapa Kubernetes Secret-objekt

Minimum i produktion: Aktivera encryption at rest för etcd (där Kubernetes lagrar all state) med en KMS-provider. På EKS använd AWS KMS, på AKS Azure Key Vault, i eu-north-1 (Stockholm) eller Sweden Central för att säkerställa datalokalitet i enlighet med GDPR.

Nätverkssäkerhet bortom grunderna

Service mesh för mTLS

Nätverkspolicyer styr vilka poddar som får prata med varandra. De krypterar inte trafiken. För att kryptera öst-väst-kommunikation behövs mutual TLS (mTLS), och det enklaste sättet att införa det är med en service mesh.

Vår erfarenhet: Linkerd ger bäst avkastning på investerad tid för team som primärt vill ha mTLS och grundläggande observabilitet. Istio motiveras först när ni behöver avancerad trafikstyrning (canary deploys, fault injection). Cilium Service Mesh är intressant för team som redan kör Cilium som CNI och vill undvika sidecar-overhead.

Ingress-säkerhet

• Kör alltid TLS-terminering med certifikat från Let's Encrypt via cert-manager
• Använd en Web Application Firewall (WAF) framför ingress — ModSecurity med CoreRuleSet eller en molnbaserad WAF
• Rate-limita API-endpoints i ingress controller-konfigurationen
• Separera externa och interna ingress-controllers så att interna tjänster aldrig exponeras mot internet

Säkerhet för kontrollplanet

API-servern är hjärtat i klustret. Komprometteras den har angriparen fullständig kontroll.

• Begränsa nätverksåtkomst till API-servern. I managerade tjänster (EKS, AKS): aktivera private endpoint och stäng av public access
• Aktivera OIDC-autentisering kopplad till er identitetsleverantör (Entra ID, Okta) istället för statiska tokens eller klientcertifikat
• Rotera certifikat regelbundet — i self-hosted-kluster automatisera detta med kubeadm eller cert-manager
• Skydda etcd — kryptera trafik till etcd, begränsa nätverksåtkomst, ta regelbundna backuper krypterade med separat nyckel

En praktisk säkerhetsmodell i fyra lager

Varje lager fångar hot som de andra missar. Att bara ha ett lager — oavsett hur bra det är — lämnar blinda fläckar.

Managerade molntjänster

Kubernetes-säkerhet och regulatoriska krav

Organisationer i EU som kör Kubernetes i produktion behöver förhålla sig till:

• GDPR — Personuppgifter i containrar kräver samma skydd som överallt annars. Encryption at rest och in transit, access logging, dataläckageprevention
• NIS2-direktivet — Krav på riskhantering, incidentrapportering inom 24 timmar och supply chain-säkerhet. Image-signering och SBOM (Software Bill of Materials) blir direkta compliance-verktyg
• IMY:s tillsyn — Integritetsskyddsmyndigheten har ökat sin granskning av tekniska skyddsåtgärder. Att kunna visa att klustret har RBAC, nätverkssegmentering och audit logging stärker er position vid tillsyn

Molnmigrering

Vanliga frågor

Vilka är de vanligaste Kubernetes-sårbarheterna?

Felkonfigurerad RBAC, containrar som körs som root, avsaknad av nätverkspolicyer och exponerade API-servrar. Enligt CNCF:s årliga undersökning är felkonfiguration konsekvent den vanligaste orsaken till säkerhetsincidenter i Kubernetes-miljöer. De flesta av dessa går att åtgärda med policy-as-code och hårdare standardinställningar.

Räcker det med nätverkspolicyer för att säkra ett kluster?

Nej. Nätverkspolicyer är en kritisk komponent men bara ett lager. Du behöver också RBAC, image-scanning, runtime-skydd, secrets-hantering och loggning. Defense in depth — flera överlappande skyddslager — är den enda hållbara strategin.

Hur hanterar man secrets säkert i Kubernetes?

Undvik att lagra hemligheter direkt i Kubernetes Secrets (som bara är base64-kodade). Använd en extern secrets-hanterare som HashiCorp Vault, AWS Secrets Manager eller Azure Key Vault med en operator som External Secrets Operator för att injicera hemligheter vid runtime.

Vad är Pod Security Standards och varför behöver jag dem?

Pod Security Standards (PSS) är Kubernetes inbyggda ramverk som ersatte PodSecurityPolicy. Det definierar tre nivåer — Privileged, Baseline och Restricted — som styr vad poddar får göra. Baseline bör vara minimum i produktion; Restricted för känsliga arbetsbelastningar.

Hur skiljer sig Kubernetes-säkerhet i en managerad tjänst jämfört med self-hosted?

Med EKS, AKS eller GKE ansvarar molnleverantören för control plane-säkerhet. Du ansvarar fortfarande för nodkonfiguration, nätverkspolicyer, RBAC, image-säkerhet och applikationslager. Shared responsibility-modellen innebär att klustret inte är säkert bara för att det är managerat.