Docker i produktion på Azure och säkerhetsaspekter som ofta glöms bort

Jag ser regelbundet miljöer där containerdeployment fungerar felfritt, där autoskalning är konfigurerad, CI/CD-pipelines är etablerade och applikationer levererar värde till verksamheten. Samtidigt är container registry tillgängligt via publika endpoints utan tillräcklig access control, images saknar digital signering, känslig information exponeras via miljövariabler, ingen har verifierat vilka systemrättigheter containrarna faktiskt kör med och base images uppdateras inte tillräckligt ofta. Det senare är vanligare än man kan tro. Speciellt när organisationer varken har rutiner för regelbunden ombyggnad av images eller container scanning på plats, är resultatet ofta produktionsmiljöer med images baserade på kraftigt föråldrade base images fyllda med kända sårbarheter.

Dessa miljöer fungerar. Tills de inte gör det.

Denna artikel fokuserar på praktiska säkerhetsaspekter som har reell påverkan på risknivå i produktionsmiljöer. Snarare än generiska compliance-checklistor adresseras konkreta säkerhetsgap som regelbundet identifieras i verkliga Azure-miljöer, samt de avvägningar mellan säkerhet och komplexitet som tekniska ledare måste ta ställning till.

Del 1: Container Registry som första försvarslinje

Image signering och verifiering

Osignerade container images utgör ett ofta underskattat hot mot supply chain-säkerhet. Utan verifiering av imageintegritet och ursprung accepterar organisationen implicit hela den underliggande byggprocessen som pålitlig, samtidigt som det är en förutsättning som sällan kan garanteras.

Azure Container Registry utgör typiskt det centrala lagret för alla container images i en Azure-miljö. Detta gör det till en strategisk kontrollpunkt.

Image signering adresserar två fundamentala risker:

Det är dock viktigt att förstå vad signering faktiskt löser, och vad den inte löser. Signering garanterar att en image inte manipulerats efter byggprocessen, men säger ingenting om vad imagen är byggd på. En utvecklare kan ta en base image full av sårbarheter eller skadlig kod, bygga en ny image och signera den enligt processen, utan att något i flödet larmar. Signering utan ursprungskontroll är som att verifiera att ett brev inte öppnats utan att kontrollera vem som skickade det.

Kontroll av imageorigin och godkända baskällor

För att adressera ursprungsfrågan behöver organisationen definiera en godkänd uppsättning base images, ofta kallat golden images eller golden path, och kräva att alla images i miljön härstammar från dessa. Både Docker Hub och Quay stödjer SHA-pinning, vilket gör det möjligt att låsa en base image till en specifik, verifierad version snarare än en rörlig tagg som ubuntu:latest.

Ett komplett kontrollflöde kombinerar därför flera lager:

1. Signera images automatiskt i CI-pipeline
2. Kräv verifiering av signatur före deployment
3. Definiera och publicera godkända base images med specifika SHA-digests i ett internt register
4. Kräv att CI-pipelines refererar base images via digest, inte enbart tagg
5. Implementera container scanning för att fånga kända sårbarheter i alla lager:  inklusive base image-lagret
6. Kombinera scanning med admission control i AKS som blockerar images som inte uppfyller policy

Exempel på GitHub Actions-implementation:

- name: Build image
  run: docker build -t myapp:${{ github.sha }} .

- name: Push image
  run: docker push myregistry.azurecr.io/myapp:${{ github.sha }}

- name: Sign image
  run: cosign sign myregistry.azurecr.io/myapp:${{ github.sha }}

För native Azure Container Registry-integration rekommenderas Notation tillsammans med Azure Key Vault för certifikatbaserad signering. Detta ger djupare integration med Azure-ekosystemet och stöd för ACR-native content trust. För container scanning rekommenderas Microsoft Defender for Containers, som ger kontinuerlig sårbarhetsbedömning direkt i ACR och AKS, eller Trivy som ett beprövat open-source-alternativ. Cosign är ett väletablerat alternativ för hybrid- och multi-cloud-miljöer. Se Microsoft Learn: Sign and verify container images with Notation.

Det väsentliga är inte vilket signeringsverktyg som används utan att deployment-processen konsekvent vägrar acceptera images utan giltig signatur, känt ursprung och godkänd sårbarhetsstatus.

Effektiv vulnerability scanning

Målsättningen om noll identifierade CVE:er är i praktiken orealistisk. Alla container images innehåller sårbarheter. Den avgörande frågan är vilka sårbarheter som är exploaterbara inom organisationens specifika kontext och hotlandskap.

Microsoft Defender for Containers erbjuder integrerad scanning av både registry och runtime-miljöer. Defender for DevOps (del av Microsoft Defender for Cloud) möjliggör scanning direkt i CI/CD-pipelines i Azure DevOps och GitHub, vilket fångar sårbarheter redan innan images når registry. GitHub Advanced Security kompletterar med CodeQL-analys och Dependabot-alerts för applikationsberoenden. Tredjepartsverktyg kan komplettera med djupare analys.

Ett effektivt sårbarhetshanteringsprogram innebär:

Tabellen ovan är ett utgångspunkt, inte ett absolut recept. Automatisk blockering vid Critical är en rimlig ambition men kräver en mogen process för att fungera i praktiken. CVE-information är inte alltid korrekt eller fullständig, undantag behöver göras, och hotfixar kan skapa situationer där en sårbarhet tekniskt sett kvarstår som Critical trots att risken reducerats avsevärt. Log4Shell är ett illustrativt exempel: den initiala patchen sänkte CVSS-score från 10 till 9, vilket fortfarande klassificeras som Critical och hade triggat en blockering trots att exponeringen faktiskt minskat. Utan en etablerad process för att hantera sådana undantag riskerar automatisk blockering att antingen brytas ned via ad-hoc-lösningar eller skapa friktion som gör att säkerhetskontrollen kringgås helt.

Dessa riktlinjer bör kombineras med exploitability-analys. En Critical CVE som inte är exploaterbar i organisationens specifika kontext, till exempel en sårbarhet i en oanvänd komponent, kan motivera undantag efter dokumenterad riskbedömning. Nyckelord: dokumenterad.

För Medium-nivå och ovan uppstår en viktig styrningsfråga som sällan adresseras explicit: vem äger risken och vem har mandat att godkänna den? I praktiken bör riskacceptans för sårbarheter ägas av en namngiven roll, typiskt applikationsägaren eller produktägaren i samråd med säkerhetsfunktionen, inte lösas informellt av den utvecklare som råkade köra bygget. Utan tydlig ägarskap tenderar dokumenterade undantag att bli en formalitet snarare än ett reellt beslut.

False positives måste hanteras systematiskt genom versionskontrollerade undantag, inte genom ad-hoc-bedömningar. I praktiken innebär detta att undantag för icke-exploaterbara CVE:er dokumenteras i en fil (t.ex. .trivyignore) som checkas in i repot med anledning, godkännare och ett utgångsdatum. De ska inte döljas via ett klick i en portal som ingen annan ser. När undantaget går ut börjar pipelinen flagga igen automatiskt. Scanning bör vara en integrerad del av Azure DevOps eller GitHub Actions-pipelines med ett exit-code som bryter builden vid nya, icke-godkända kritiska fynd. Automatiskt och inte en manuell kontrollpunkt. Det tvingar fram ett spårbart beslut: patcha, dokumentera undantag, eller acceptera en röd build.

Access patterns för registry

Managed identities bör föredras framför service principals när tekniskt möjligt, särskilt i AKS-miljöer. Detta eliminerar hantering av client secrets som i sig utgör en säkerhetsrisk.

Följ principen om least privilege: tillämpa repository-scoped permissions snarare än registry-level access när det är möjligt. Azure Container Registry stödjer nu Azure ABAC (Attribute-Based Access Control) för repository-scoped permissions, vilket möjliggör finkornad åtkomstkontroll baserad på attribut som repository-namn. Detta är ett kraftfullt komplement till traditionell RBAC och rekommenderas för miljöer med många team som delar ett gemensamt registry. Se Microsoft Learn: Azure ABAC for repository permissions in ACR för implementation.

Private endpoints för Azure Container Registry är värdefulla när registry konsumeras från privata nätverk. Men de är inte universellt nödvändiga. I miljöer med väletablerad RBAC och där administrativa credentials inte cirkulerar kan publika endpoints med robust autentisering utgöra en acceptabel risknivå.

Observera dock att organisationer med regulatoriska krav (t.ex. NIS2, hälsovårdssektorn, finansiella tjänster) ofta måste implementera private endpoints oavsett RBAC-styrka. Denna bedömning kräver en avvägning mellan operationell komplexitet, riskprofil och compliance-krav.

Del 2: Runtime security när containern är i drift

Hemlighetsmakeri

Den vanligaste säkerhetsbristen i containerdeployments är exponering av känslig information via environment variables, eller ännu värre: inbakad direkt i container images.

Azure Key Vault bör vara den centrala lösningen för secrets management.

I AKS-miljöer är CSI driver-mönstret moget och produktionsredo. Ett alternativ är External Secrets Operator (ESO), som synkroniserar Key Vault-secrets till Kubernetes Secrets-objekt vilket passar bättre i miljöer med befintliga Helm-baserade deployments eller multi-cloud-behov. Rekommenderat flöde med CSI driver:

1. Pod använder workload-specific managed identity (via AKS Workload Identity med federated credentials, vilket ersätter det äldre pod identity-mönstret och möjliggör också access mot andra Azure PaaS-tjänster som Storage, Service Bus och Cosmos DB utan credentials)
2. Identity har konfigurerad access policy i Key Vault
3. Secrets monteras som filer, inte environment variables

Exempel på säker pod-konfiguration:

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: app
    image: myregistry.azurecr.io/app:1.0
    securityContext:
      runAsNonRoot: true
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: secrets-store
      mountPath: "/mnt/secrets"
      readOnly: true
  volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true

Fullständig konfiguration kräver även en SecretProviderClass-resurs som definierar Key Vault-koppling och vilka secrets som ska monteras. Se Azure documentation: Use the Azure Key Vault provider for Secrets Store CSI Driver för komplett exempel.

Rotation av secrets utan driftstopp kräver att applikationen kan läsa om monterade filer dynamiskt. Detta är primärt en applikationsarkitekturfråga snarare än en infrastrukturfråga.

Network isolation

Default deny via Network Policies i AKS utgör en stark säkerhetsbaseline. Observera att network policy plugin måste konfigureras vid AKS cluster creation (via --network-policy azure eller --network-policy calico) och kan inte aktiveras retroaktivt i befintliga kluster.

Exempel på grundläggande policy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Därefter öppnas kommunikationsvägar explicit baserat på dokumenterade krav.

Service mesh-lösningar som Istio eller Linkerd kan tillhandahålla mTLS och förbättrad observability. Men den operationella komplexiteten är betydande vilket medför service mesh-uppgraderingar, mTLS-certifikathantering och ökad felsökningskomplexitet. Denna arkitektur motiveras främst när organisationen har många interna tjänster med hög konfidentialitet och etablerad kompetens för att hantera komplexiteten.

Ingress-konfiguration underskattas ofta. Felaktig NGINX- eller Traefik-konfiguration kan oavsiktligt exponera interna tjänster. Begränsa path-routing explicit, använd TLS konsekvent, och inaktivera onödiga annotations.

Policy enforcement via admission controllers är ett AKS-specifikt verktyg för att påtvinga säkerhetskrav i klustret. Azure Policy för AKS (baserat på Gatekeeper) ger färdigdefinierade policies för vanliga säkerhetskrav och integrerar med Azure Policy-portalen. Kyverno är ett open-source-alternativ med ett mer Kubernetes-nativt policyspråk och stöd för mutation av resurser vid deployment. Detta är användbart för att automatiskt applicera säkerhetskontroller som non-root-körning och read-only-filsystem.

Least privilege containers

Att köra containrar som root-användare är fortfarande vanligt förekommande, trots att det utgör en onödig riskexponering.

Exempel på Dockerfile med non-root user:

FROM mcr.microsoft.com/dotnet/aspnet:8.0
RUN adduser --disabled-password appuser
USER appuser

Linux capabilities bör begränsas till vad som faktiskt krävs. De flesta applikationer behöver inte NET_ADMIN eller SYS_ADMIN. Varje reducerad capability minskar blast radius vid potentiell kompromiss.

Del 3: Supply chain security

Base image-strategi

Microsoft-maintained base images är generellt bättre underhållna och får snabbare säkerhetsuppdateringar än community-drivna alternativ. Microsoft rekommenderar i sin AKS-dokumentation att regelbundet uppdatera base images och applikationsruntimes, samt att använda automation för att bygga om downstream images när en base image uppdateras (se Operator best practices for container image management in AKS, Microsoft Learn).

Distroless images reducerar attackytan genom att exkludera shell och package managers. Microsoft rekommenderar explicit användning av distroless images som base images för att reducera attackytan, vilket också är i linje med deras Containers Secure Supply Chain-ramverk (se Build Stage, Microsoft Learn). Detta komplicerar dock felsökning, men i regel bör felsökning inte ske direkt mot en applikations image. Ett praktiskt mönster är att istället deploya en separat utility container vid behov, med de verktyg som krävs för diagnostik, och ta bort den när felsökningen är klar. Det ger både en renare säkerhetsprofil i produktion och bibehållen operativ flexibilitet när något väl behöver undersökas.

Multi-stage builds reducerar slutlig image-storlek och exponerade verktyg:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
COPY --from=build /app /app
WORKDIR /app
ENTRYPOINT ["dotnet", "MyApp.dll"]

Detta är en lågkomplexitetsåtgärd med betydande säkerhetseffekt.

Dependency management

Scanning måste omfatta både OS-paket och applikationsberoenden.

Automatisera uppdateringar via Dependabot eller Renovate, men etablera tydliga godkännandeprocesser. Utan struktur ackumuleras teknisk skuld snabbt.

Build pipeline hardening

Generera Software Bill of Materials (SBOM) och lagra tillsammans med image metadata för spårbarhet. SBOM skiljer sig från befintliga manifestfiler som csproj och package.json, vilka listar direkta beroenden, medan en SBOM representerar det kompletta beroendeträdet inklusive transitiva beroenden, OS-paket och bibliotek i base image. Verktyg som Syft (integrerat i GitHub Advanced Security) genererar SBOM i standardiserade format (SPDX, CycloneDX) som kan importeras av sårbarhetshanteringsverktyg. För organisationer med NIS2-krav börjar SBOM bli ett krav snarare än en rekommendation.

Använd ephemeral build agents. Undvik långlivade self-hosted runners med breda rättigheter. Nätverksisolerade agenter med begränsad line-of-sight mot interna system reducerar blast radius vid en komprometterad pipeline. Agenten ska kunna nå registry och deployment-target, men inte bredare intern infrastruktur.

Separera build- och deploy-permissions rigoröst. En komprometterad pipeline ska inte automatiskt kunna deploya till produktionsmiljö.

Del 4: Logging och monitoring

Vad som faktiskt behöver loggas

Dirigera container stdout/stderr till Azure Log Analytics. För organisationer med befintliga investeringar i tredjepartsverktyg är Datadog, Elastic och Grafana Loki vanliga alternativ som kan komplettera eller ersätta Log Analytics beroende på befintlig plattformsstrategi.

Kostnadsbilden skiljer sig dock markant mellan alternativen. Splunk och Datadog innebär typiskt betydande licensieringskostnader som skalas med datavolym och antal noder. Elasticsearch och Grafana Loki däremot körs ofta self-hosted, de kan till och med deployas i samma kluster som applikationerna, vilket gör dem avsevärt mer kostnadseffektiva. Avvägningen handlar då istället om intern driftskostnad och operativ komplexitet kontra en färdig managed-tjänst. För organisationer med begränsade plattformsteam kan den förvaltningsbörda som self-hosted lösningar medför äta upp en stor del av den initiala kostnadsbesparingen.

Kritiska händelser att logga:

Runtime behavior monitoring via Defender for Containers kan detektera avvikande processer och kommunikationsmönster. Detta sker via eBPF-baserade sensorer (i Linux-nodpooler) eller DaemonSet-agenter som moniterar syscall-aktivitet i realtid. Detektionsförmågan är stark för kända attackmönster såsom lateral movement, privilege escalation, crypto mining, men bör kompletteras med applikationsspecifika alerts för affärslogik-avvikelser som verktyget inte känner till.

Alert fatigue

Alla alerts har inte lika stor betydelse. Severity-nivåer måste reflektera verklig affärsrisk.

Produktionsmiljöer ska ha striktare detektionsregler än utvecklingsmiljöer. Annars riskerar organisationen alert fatigue och ignorerade signaler.

Integrera med etablerade incident response-processer. Ett alert utan tydligt ägarskap och eskaleringsväg genererar endast brus.

Del 5: Disaster recovery och incident response

Backup av container infrastructure

GitOps utgör en robust disaster recovery-strategi. Om ett helt kluster förloras ska organisationen kunna återskapa det från versionskontrollerad kod. En komplett backup-strategi för containerinfrastruktur bör adressera tre lager: Azure infrastruktur med IaC (Terraform eller Bicep) säkerställer att plattformen kan rekonstrueras deterministiskt; persistenta volymer, databaser och lagring säkerhetskopieras med dedikerade backup-lösningar som Azure Backup och Recovery Services Vaults; samt tjänster och klusterkonfiguration via GitOps, där Flux eller ArgoCD säkerställer att applikationsstacken kan återställas från Git-historiken.

ACR geo-replication reducerar risk associerad med regionala Azure-avbrott. ACR soft delete-policy bör även aktiveras. Detta möjliggör återställning av oavsiktligt raderade images och tags inom en konfigurerbar retentionsperiod (upp till 90 dagar), vilket är värdefullt både för incident response och som skydd mot accidentell eller maliciös radering.

State i persistent volumes kräver separat hantering. Backup av data är inte identiskt med backup av images.

Incident response

Container forensics inleds med att:

1. Frysa specifik image version
2. Exportera container filesystem
3. Analysera processer och nätverksanslutningar

Rollback-strategier måste vara testade och verifierade, inte endast dokumenterade teoretiskt.

Post-incident analysis bör inkludera förnyad analys av aktuell image. Sårbarheter identifieras ibland först retroaktivt.

Sammanfattning och prioriteringar

Avvägningen mellan säkerhetskontroller och operationell komplexitet är alltid kontextspecifik. Inte alla åtgärder är motiverade att implementera omedelbart.

Tre högt prioriterade åtgärder med betydande effekt och relativt låg komplexitet:

1. Kör alla containers som non-root användare
2. Migrera all secrets-hantering till Key Vault med managed identities
3. Implementera vulnerability scanning med riskbaserade tröskelvärden

Dessa ger substantiell riskreduktion med hanterbar implementationskomplexitet.

Referenser

1. Microsoft Learn: Azure Container Registry documentation
2. Microsoft Learn: Microsoft Defender for Containers overview
3. Microsoft Learn: Azure Key Vault documentation
4. Microsoft Learn: AKS security best practices