Containersikkerhet: herding av imager og beskyttelse under kjøring

Containere pakker applikasjonskode og avhengighetene dens i isolerte enheter som deler vertsoperativsystemets kjerne, i motsetning til VM-er, som inkluderer et komplett gjesteoperativsystem. Denne delingen gjør containere lette og raske, men introduserer en annen sikkerhetsmodell: En sårbarhet som gjør det mulig å unnslippe en container, kan gi en angriper mulighet til å bryte seg ut av containeren og få direkte tilgang til vertens kjerne, noe som påvirker alle andre containere. Containersikkerhet fokuserer på tre lag: imaget (det som bygges inn), runtime-miljøet (det containeren kan gjøre mens den kjører) og orkestreringsplattformen (hvordan containere administreres).

Hver pakke som installeres i et containerimage, er en potensiell angrepsflate. Prinsippet med minimale baseimages innebærer å starte med det minst mulige grunnlaget: Alpine Linux (5 MB, minimale pakker), distroless-images (Googles images som bare inneholder runtime-miljøet og applikasjonen, uten shell eller pakkebehandler) eller scratch (helt tomt, for statisk kompilerte binærfiler). En container uten shell betyr at en angriper som oppnår kodekjøring, ikke enkelt kan kjøre wget, curl eller andre verktøy for å utvide angrepet – et prinsipp som kalles forsvar gjennom minimal eksponering.

Som standard kjører Docker-containere som root (UID 0). Hvis en angriper utnytter en sårbarhet i den containeriserte applikasjonen, får angriperen root-rettigheter inne i containeren. Hvis containeren deler et volum eller har monteringer fra verten, kan root inne i containeren være det samme som root på verten. Løsningen er enkel: opprett en dedikert bruker i Dockerfile og bytt til denne med USER-direktivet før den endelige CMD/ENTRYPOINT. Mange verktøy for skanning av containersikkerhet vil rapportere alle images uten en ikke-root-bruker som et funn.

Uforanderlige containere er containere der filsystemet ikke kan endres under kjøring. Når --read-only aktiveres i Docker (eller readOnlyRootFilesystem: true i Kubernetes), hindres angripere i å skrive skadevare til disken, endre konfigurasjonsfiler eller installere verktøy i en container som kjører. Applikasjoner som faktisk trenger å skrive data (logger, midlertidige filer), kan montere bestemte tmpfs-volumer for midlertidige skrivinger. Uforanderlige containere håndhever prinsippet om at runtime-tilstanden bare skal komme fra imaget og konfigurasjonen, ikke fra endringer inne i containeren som omgår sikkerhetspipelinen for CI/CD.

Verktøy for skanning av containeravbildninger analyserer pakkene som er installert i en Docker-avbildning, opp mot sårbarhetsdatabaser (NVD, CVE), og rapporterer kjente CVE-er. Ledende skannere inkluderer Trivy (Aqua Security, rask og kostnadsfri), Grype (Anchore), Snyk Container og AWS ECR image scanning. Skanning bør integreres i CI/CD-pipelinen, slik at alle avbildninger med kritiske eller alvorlige CVE-er får pipelinen til å feile før de pushes til et register. Skannerne bør også se etter hemmeligheter (API-nøkler, passord) som ved et uhell er bygget inn i avbildningslag.

En vanlig og farlig feil er å bygge inn hemmeligheter (API-nøkler, databasepassord, TLS-sertifikater) i Docker-avbildninger — enten i miljøvariabler som er bakt inn i avbildningen, eller i filer som er lagt til via COPY. Disse hemmelighetene er synlige for alle som har tilgang til avbildningen, via docker history eller ved å trekke ut avbildningslagene. Selv om et påfølgende lag sletter filen, blir den værende i avbildningshistorikken. Hemmeligheter bør injiseres ved kjøring via miljøvariabler fra en hemmelighetshåndterer, Docker secrets eller Kubernetes Secrets som monteres som volumer.

Sikkerhetsverktøy for kjøring overvåker oppførselen til containere mens de kjører, og varsler om eller blokkerer unormal aktivitet. Falco (et CNCF-prosjekt kobler seg til Linux-kjernen ved hjelp av eBPF eller kjernemoduler for å fange opp systemkall og sammenligne dem med regler. En regel kan for eksempel varsle hvis en container starter et skall (execve('/bin/sh')), åpner en nettverkstilkobling på en uventet port eller leser /etc/shadow. Slike atferdsindikatorer signaliserer ofte et aktivt angrep, selv om ingen kjent CVE er blitt utnyttet. Sysdig Secure og Aqua Security tilbyr kommersielle plattformer for beskyttelse ved kjøring.

Docker-containere forkaster som standard mange Linux-funksjoner, men beholder fortsatt flere enn de fleste applikasjoner trenger. Capabilities deler root-rettigheter opp i separate enheter (for eksempel CAP_NET_ADMIN og CAP_SYS_ADMIN). Anbefalt praksis er å forkaste alle funksjoner og bare legge tilbake det som kreves, med --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Profiler for Seccomp (Secure Computing Mode) angir hvilke systemkall en container kan utføre — Docker inkluderer en standardprofil for seccomp som blokkerer rundt 44 farlige systemkall. Egendefinerte seccomp-profiler for bestemte applikasjoner kan begrense dette ytterligere ved å blokkere alle systemkall applikasjonen aldri legitimt bruker.

Containerregistre (Docker Hub, AWS ECR, Google Artifact Registry) lagrer og distribuerer avbildninger. Sikring av registeret innebærer å: aktivere sårbarhetsskanning ved push, begrense push-tilgang til CI/CD-tjenestekontoer, aktivere signering av avbildninger ved hjelp av Sigstore/Cosign eller Docker Content Trust (Notary), slik at kjøremiljøer bare henter kryptografisk signerte avbildninger fra pålitelige kilder, og konfigurere uforanderlighet for avbildninger, slik at tagger ikke kan overskrives. Dette eliminerer angrep med endring av tagger, der en angriper erstatter en pålitelig :latest-tagg med en ondsinnet avbildning.

Angripere som oppnår kodekjøring inne i en container, kan forsøke containerflukt for å få tilgang til verten. Vanlige teknikker inkluderer å utnytte sårbare privilegerte containere (--privileged gir nesten ubegrenset tilgang til verten), misbruke eksponerte Docker-sockets (/var/run/docker.sock montert i en container gir full tilgang til Docker-API-et, inkludert muligheten til å opprette privilegerte containere) og utnytte kjerne­sårbarheter via usikrede funksjoner. Forsvarstiltak er å aldri bruke privilegert modus med mindre det er absolutt nødvendig, aldri montere Docker-socketen i applikasjonscontainere, holde vertskjernen oppdatert og bruke gVisor eller Kata Containers for arbeidslaster som krever sterk isolasjon.

Center for Internet Security (CIS) Docker Benchmark inneholder detaljerte retningslinjer for sikkerhetskonfigurering av Docker-verter og -containere, inkludert daemon-konfigurasjon, ryddige avbildninger, innstillinger for kjøring av containere og nettverkskontroller. Verktøy som Docker Bench for Security automatiserer etterlevelseskontroll mot CIS-standarden og genererer en poengsatt rapport over beståtte og ikke beståtte punkter. Ved å kjøre denne testen med jevne mellomrom og integrere den i CI/CD blir konfigurasjonsavvik i sikkerheten oppdaget raskt. Security+-kandidater bør vite at CIS Benchmarks er en sentral referanse for sikring av operativsystemer og plattformer i eksamenssammenheng.

I denne leksjonen har De lært at minimale basisavbildninger og brukere uten root-rettigheter reduserer angrepsflaten og privilegienivået til containeriserte arbeidslaster, at verktøy for beskyttelse ved kjøring, som Falco, oppdager unormale mønstre i systemkall som tyder på aktive angrep i containere, og at De aldri bør bruke privilegerte containere eller montere Docker-socketen i applikasjonscontainere, ettersom disse konfigurasjonene muliggjør containerflukt. Neste tema er Kubernetes-sikkerhet, inkludert RBAC, nettverkspolicyer og sikkerhetsstandarder for pods.