Security+ Academy · Lektion

Containersikkerhed: hærdning af images og runtime-beskyttelse

Hærd Docker-images ved at fjerne unødvendige pakker, køre som ikke-root-bruger og bruge runtime-sikkerhedsværktøjer (Falco, Sysdig) til at opdage unormal containeradfærd.

Lektion 1 af 413 trin

Containersikkerhed: hærdning af images og runtime-beskyttelse er en gratis Security+ Academy-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Security+ Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Security+ Academy-kurset indeholder 4 lektioner i alt.

Grundlæggende om containersikkerhed

Containere pakker programkode og dens afhængigheder i isolerede enheder, der deler værtsoperativsystemets kerne, i modsætning til VM'er, som indeholder et komplet gæsteoperativsystem. Denne deling gør containere lette og hurtige, men indfører en anden sikkerhedsmodel: En sårbarhed, der gør det muligt at bryde ud af en container, kan give en angriber mulighed for at bryde ud af containeren og få direkte adgang til værtskernens funktioner, hvilket påvirker alle andre containere. Containersikkerhed fokuserer på tre lag: image'et (det, der er indbygget), kørselstiden (det, containeren kan gøre under kørsel), og orkestreringsplatformen (hvordan containere administreres).

Minimale base-images: reduktion af angrebsfladen

Hver pakke, der installeres i et containerimage, er en potentiel angrebsflade. Princippet om minimale base-images betyder, at man starter med det mindst mulige grundlag: Alpine Linux (5 MB, minimale pakker), distroless-images (Googles images, der kun indeholder kørselstiden og applikationen, uden shell eller pakkehåndtering) eller scratch (helt tomt, til statisk kompilerede binærfiler). En container uden shell betyder, at en angriber, der opnår kodekørsel, ikke nemt kan køre wget, curl eller andre værktøjer for at udvide sit angreb — et princip, der kaldes forsvar gennem minimal eksponering.

# Bad: starts from a full OS image
FROM ubuntu:22.04

# Better: minimal Alpine base
FROM alpine:3.18

# Best: distroless for Java apps
FROM gcr.io/distroless/java17-debian11

Kørsel som ikke-root-bruger: den første regel

Som standard kører Docker-containere som root (UID 0). Hvis en angriber udnytter en sårbarhed i den containeriserede applikation, får angriberen root-rettigheder i containeren. Hvis containeren deler en diskenhed eller har monteringer fra værten, kan root i containeren være det samme som root på værten. Løsningen er enkel: Opret en dedikeret bruger i Dockerfile, og skift til den med USER-direktivet før den endelige CMD/ENTRYPOINT. Mange værktøjer til scanning af containersikkerhed markerer alle images uden en ikke-root-bruger som et fund.

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup app /app/app
USER appuser
CMD ["/app/app"]

Uforanderlige containere og skrivebeskyttede filsystemer

Uforanderlige containere er containere, hvis filsystem ikke kan ændres under kørsel. Hvis --read-only aktiveres i Docker (eller readOnlyRootFilesystem: true i Kubernetes), forhindres angribere i at skrive malware til disken, ændre konfigurationsfiler eller installere værktøjer i en kørende container. Applikationer, der reelt har brug for at skrive data (logfiler og midlertidige filer), kan montere specifikke tmpfs-diskenheder til midlertidige skrivninger. Uforanderlige containere håndhæver princippet om, at tilstanden under kørsel kun skal komme fra image'et og konfigurationen, ikke fra ændringer inde i containeren, der omgår din CI/CD-sikkerhedspipeline.

# Run container with read-only root filesystem
docker run --read-only \
  --tmpfs /tmp \
  --tmpfs /var/run \
  myapp:latest

Scanning af images: Find CVE'er før udrulning

Værktøjer til scanning af container-images analyserer de pakker, der er installeret i et Docker-image, op imod sårbarhedsdatabaser (NVD, CVE) og rapporterer kendte CVE'er. Førende scannere omfatter Trivy (Aqua Security, hurtig og gratis), Grype (Anchore), Snyk Container og AWS ECR image scanning. Scanning bør integreres i CI/CD-pipelinen, så alle images med kritiske eller alvorlige CVE'er får pipelinen til at mislykkes, før de pushes til et registry. Scannere bør også kontrollere, om der findes hemmeligheder (API-nøgler, adgangskoder), som ved et uheld er indlejret i imagelag.

# Scan a Docker image with Trivy
trivy image --severity HIGH,CRITICAL myapp:latest

# Fail CI pipeline if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latest

Håndtering af hemmeligheder: Aldrig i imagelag

En almindelig og farlig fejl er at indlejre hemmeligheder (API-nøgler, databaseadgangskoder, TLS-certifikater) i Docker-images — enten i miljøvariabler, der er indbagt i imaget, eller i filer, der tilføjes via COPY. Disse hemmeligheder er synlige for alle, der har adgang til imaget, via docker history eller ved at udpakke imagelagene. Selv hvis et efterfølgende lag sletter filen, forbliver den i imagets historik. Hemmeligheder bør injiceres ved kørsel via miljøvariabler fra en secrets manager, Docker secrets eller Kubernetes Secrets, der monteres som volumes.

# Never bake secrets into images
# Bad: ENV DATABASE_PASSWORD='supersecret'

# Good: inject at runtime via environment
docker run -e DATABASE_PASSWORD=$(vault read -field=password secret/db) myapp:latest

# Or use Docker secrets in Swarm/K8s

Beskyttelse under kørsel: Falco og syscall-overvågning

Sikkerhedsværktøjer til kørsel overvåger containeres adfærd, mens de kører, og advarer om eller blokerer unormal aktivitet. Falco (et CNCF-projekt kobler sig på Linux-kernen ved hjælp af eBPF eller kernemoduler for at opfange systemkald og sammenligne dem med regler. En regel kan f.eks. udløse en advarsel, hvis en container starter en shell (execve('/bin/sh')), åbner en netværksforbindelse på en uventet port eller læser /etc/shadow. Disse adfærdsmæssige indikatorer signalerer ofte et aktivt angreb, selv hvis ingen kendt CVE er blevet udnyttet. Sysdig Secure og Aqua Security tilbyder kommercielle platforme til beskyttelse under kørsel.

# Example Falco rule: alert on shell execution in container
# - rule: Shell Spawned in Container
#   desc: A shell was spawned in a container
#   condition: container and proc.name in (bash, sh, zsh)
#   output: Shell spawned (user=%user.name container=%container.name)
#   priority: WARNING

Linux-funktioner og Seccomp-profiler

Docker-containere fjerner som standard mange Linux-funktioner, men beholder stadig flere, end de fleste applikationer har brug for. Funktioner opdeler root-privilegier i separate enheder (f.eks. CAP_NET_ADMIN, CAP_SYS_ADMIN). Den bedste praksis er at fjerne alle funktioner og kun tilføje det, der kræves, med --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Profiler for Seccomp (Secure Computing Mode) angiver, hvilke systemkald en container må foretage — Docker indeholder en standardprofil for seccomp, der blokerer cirka 44 farlige systemkald. Brugerdefinerede seccomp-profiler til specifikke applikationer kan begrænse dette yderligere ved at blokere alle systemkald, som applikationen aldrig legitimt bruger.

# Drop all capabilities, add only what's needed
docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt seccomp=/etc/docker/seccomp-custom.json \
  myapp:latest

Containerregistries og signering af images

Containerregistries (Docker Hub, AWS ECR, Google Artifact Registry) gemmer og distribuerer images. Sikring af et registry omfatter: aktivering af sårbarhedsscanning ved push, begrænsning af push-adgang til CI/CD-tjenestekonti, aktivering af signering af images med Sigstore/Cosign eller Docker Content Trust (Notary), så miljøer under kørsel kun henter kryptografisk signerede images fra pålidelige kilder, samt konfiguration af uforanderlighed for images, så tags ikke kan overskrives. Det eliminerer angreb med ændring af tags, hvor en angriber erstatter et pålideligt :latest-tag med et ondsindet image.

# Sign a container image with Cosign
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3

# Verify signature before deployment
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3

Teknikker til container-escape og forsvar

Angribere, der opnår kodekørsel i en container, kan forsøge at udføre container-escape for at få adgang til værten. Almindelige teknikker omfatter: udnyttelse af sårbare privilegerede containere (--privileged giver næsten ubegrænset adgang til værten), misbrug af eksponerede Docker-sockets (/var/run/docker.sock monteret i en container giver fuld adgang til Docker-API'et, herunder mulighed for at oprette privilegerede containere) samt udnyttelse af kernesårbarheder via usikrede funktioner. Forsvar: Brug aldrig privilegeret tilstand, medmindre det er absolut nødvendigt, montér aldrig Docker-socketen i applikationscontainere, hold værtens kerne opdateret, og brug gVisor eller Kata Containers til workloads, der kræver stærk isolation.

# DANGEROUS: never do this in production
# docker run --privileged -v /:/host myapp:latest

# Check if a container is running privileged
docker inspect mycontainer | grep -i privileged

Overholdelse af CIS Docker Benchmark

Center for Internet Security (CIS) Docker Benchmark indeholder detaljerede retningslinjer for sikkerhedskonfiguration af Docker-værter og containere. Retningslinjerne dækker daemon-konfiguration, image-hygiejne, indstillinger for containerkørsel og netværkskontroller. Værktøjer som Docker Bench for Security automatiserer overensstemmelseskontrol op imod CIS-benchmarket og genererer en vurderet rapport med elementer, der er bestået eller ikke bestået. Hvis du kører dette benchmark regelmæssigt og integrerer det i CI/CD, sikrer du, at afvigelser i sikkerhedskonfigurationen opdages hurtigt. Security+-kandidater bør vide, at CIS Benchmarks er en primær reference til hærdning af operativsystemer og platforme i eksamenssammenhæng.

# Run Docker Bench for Security
docker run -it --net host --pid host --userns host --cap-add audit_control \
  -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc:/etc docker/docker-bench-security

Hurtigt tjek

Test din forståelse af begreberne fra CompTIA Security+ (SY0-701) i denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion har du lært, at minimale basis-images og brugere, der ikke er root, reducerer angrebsfladen og privilegieniveauet for containeriserede workloads, at værktøjer til beskyttelse under kørsel som Falco opdager unormale mønstre i systemkald, der tyder på aktive angreb i containere, og at du aldrig bør bruge privilegerede containere eller montere Docker-socketen i applikationscontainere, da disse konfigurationer muliggør container-escape. Næste emne er Kubernetes-sikkerhed, herunder RBAC, netværkspolitikker og sikkerhedsstandarder for pods.

Gratis at komme i gang

Lær Security+ Academy med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Containersikkerhed: hærdning af images og runtime-beskyttelse” gratis?

Ja — alle 3 lektioner i læringssporet Security+ Academy, inklusive “Containersikkerhed: hærdning af images og runtime-beskyttelse”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Security+ Academy-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Containersikkerhed: hærdning af images og runtime-beskyttelse”?

Hærd Docker-images ved at fjerne unødvendige pakker, køre som ikke-root-bruger og bruge runtime-sikkerhedsværktøjer (Falco, Sysdig) til at opdage unormal containeradfærd. Du øver dig i Security+ Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Security+ Academy?

Der kræves ingen tidligere erfaring. Security+ Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.

Hvor lang tid tager lektionen “Containersikkerhed: hærdning af images og runtime-beskyttelse”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Security+ Academy-lektion?

Ja. Alle Security+ Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Containersikkerhed: hærdning af images og runtime-beskyttelse
Kubernetes-sikkerhed: RBAC, netværkspolitikker og pod-sikkerhed
Serverless- og funktionssikkerhed
Sikkerhedsscanning af Infrastructure as Code

← Tilbage til Security+ Academy