Forsvar mot container-escape: En praktisk guide til Docker-isolasjon for flerleietjenester

Sammendrag

Docker-containere deler verts-kjernen, noe som gjør isolasjon kritisk – spesielt i flerleietjenester der en enkelt container-escape kan kompromittere alle leietakere. Mange utviklere antar at containere er perfekt isolerte virtuelle maskiner, men virkeligheten er annerledes. Denne artikkelen forklarer Linux-kjernens funksjoner bak Docker-isolasjon (navnerom, cgroups) og angrepsvektorene som truer dem. Du vil lære praktiske trinn for å herde Docker-oppsettet ditt: begrense privilegier, bruke sikker kjøretid, skanne bilder og implementere nettverkssegmentering. Ved å følge et reelt eksempel på en flerleiet WordPress-hostingleverandør, vil du se hvordan du anvender disse forsvarsmekanismene. Vi dekker også forbehold som ytelseskompromisser og bruk av seccomp/AppArmor. Målet er å gi deg en robust isolasjonsstrategi som forhindrer container-escape og holder leietakerne dine trygge.

Introduksjon

Hvis du driver en flerleiet hostingplattform – enten det er delt WordPress-hosting, en SaaS-applikasjon eller en utviklingsmiljøtjeneste – er container-escape marerittscenarioet. En sårbarhet i kjernen eller en feilkonfigurasjon kan la en leietaker bryte ut av sin container og få tilgang til andre leietakeres data eller selve verten. Dockers isolasjon er avhengig av Linux-kjernens funksjoner som navnerom og cgroups, men standardkonfigurasjoner er ofte utilstrekkelige for robust sikkerhet. Denne artikkelen vil guide deg gjennom angrepsvektorene og gi handlingsrettede trinn for å låse ned Docker-containerne dine, illustrert med et reelt flerleiet WordPress-eksempel. For en bredere oversikt over produksjonsorkestrering, se vår guide om Orkestrering av produksjonsklare containeriserte applikasjoner.

Forstå Docker-isolasjon

Docker-containere bruker Linux-navnerom for å gi prosessnivå-isolasjon: PID-navnerom isolerer prosesshierarkier, nettverksnavnerom skiller nettverksgrensesnitt, monteringsnavnerom isolerer filsystemmonteringer, og bruker-navnerom tillater mapping av container-root til en uprivilegert vertsbruker. Kontrollgrupper (cgroups) begrenser ressursbruk som CPU, minne og disk I/O. Disse funksjonene skaper sammen en "sandkasse" rundt hver container. Men i motsetning til en virtuell maskin som kjører en separat kjerne, deler containere vertskjernen. Dette betyr at en sårbarhet i kjernen (f.eks. CVE-2022-0492) kan utnyttes for å bryte ut av containerens navneromsisolasjon. I tillegg kan feilkonfigurasjoner som å kjøre containere som root inne i containeren, gi containeren alle kapabiliteter, eller ikke slippe unødvendige Linux-kapabiliteter, utvide angrepsflaten.

Angrepsvektorer

Vanlige angrepsvektorer inkluderer:

• Kjerne-utnyttelser: Utnytte en feil i vertskjernen for å få vertstilgang.
• Privilegerte containere: Kjøring med --privileged gir alle kapabiliteter og omgår de fleste isolasjonsmekanismer.
• Misbruk av kapabiliteter: Selv uten full privilegert modus, kan en container med farlige kapabiliteter som CAP_SYS_ADMIN eller CAP_NET_ADMIN montere filsystemer eller manipulere nettverksinnstillinger.
• Usikre bilde-praksiser: Bruke basisbilder med kjente sårbarheter eller inkludere unødvendige verktøy som kompilatorer eller skalltolkere.
• Delte monteringsnavnerom: Montering av vertskataloger inn i containere kan tillate escape hvis de ikke er skrivebeskyttet.

Praktiske sikkerhetstrinn

1. Kjør containere som en ikke-root-bruker

Som standard kjører Docker containere som root inne i containeren. Hvis en angriper får root-tilgang inne i containeren, har de mer innflytelse. Opprett en bruker i Dockerfilen din og bruk USER-direktivet. Unngå også å bruke --user-flagget i Docker Compose for å mappe til en vilkårlig vertsbruker hvis mulig.

2. Slipp alle kapabiliteter og legg kun til nødvendige

Linux-kapabiliteter bryter ned superbrukerprivilegier i mindre enheter. I Docker Compose, bruk cap_drop: ALL og deretter cap_add kun de nødvendige (f.eks. NET_BIND_SERVICE). Unngå farlige kapabiliteter som SYS_ADMIN, NET_ADMIN, SYS_PTRACE.

3. Bruk skrivebeskyttet rotfilsystem

Sett read_only: true i containerdefinisjonen din. Dette forhindrer angripere i å skrive til containerens filsystem. Hvis applikasjonen din trenger å skrive midlertidige filer, monter et tmpfs-volum på den plasseringen.

4. Aktiver bruker-navnerom-ommapping

Bruker-navnerom-ommapping mapper containerens root-bruker til en ikke-root vertsbruker. Dette legger til et isolasjonslag, da selv om en container-root bryter ut, vil de ha privilegiene til den ommappede brukeren. Aktiver det i /etc/docker/daemon.json med "userns-remap": "default". Vær oppmerksom på at dette kan komplisere volumtillatelser. For mer detaljer, se Mestring av Docker-isolasjon for sikker og effektiv webhosting.

5. Bruk Seccomp og AppArmor/AppArmor-profiler

Seccomp begrenser systemkallene en container kan utføre. Docker leverer en standard seccomp-profil som blokkerer farlige systemkall. Du kan også lage egendefinerte profiler. Tilsvarende gir AppArmor (eller SELinux) obligatorisk tilgangskontroll. Bruk AppArmor for å begrense containeren din til et minimalt sett med tillatte operasjoner. Sikkerhetsprofilen kan settes via security_opt i Docker Compose.

6. Bruk minimale basisbilder og skann for sårbarheter

Velg små bilder som Alpine eller Distroless som har en mindre angrepsflate. Skann jevnlig bilder med verktøy som Docker Scout, Trivy eller Clair. Integrer skanning i CI/CD-pipelinen din for å forhindre at sårbare bilder blir distribuert.

7. Nettverkssegmentering med egendefinerte bro-nettverk

Opprett separate bro-nettverk for hver leietaker eller applikasjonsnivå. Dette begrenser øst-vest-trafikk. I Docker Compose, definer nettverk og isoler tjenester. Bruk internal: true hvis en tjeneste ikke trenger utgående internettilgang. Brannmurregler på verten begrenser ytterligere trafikk mellom containere.

8. Begrens ressurser med Cgroups

Sett CPU- og minnegrenser i Docker Compose ved hjelp av deploy.resources.limits. Dette forhindrer en kompromittert container i å starte et ressursutarmingsangrep. I tillegg, sett kernel_memory og memory_reservation for finere kontroll.

Reelt eksempel: Flerleiet WordPress-hosting med Docker Compose

Vurder et scenario der du hoster flere WordPress-sider for forskjellige kunder, hver i sin egen Docker-container. Et usikkert oppsett kan se slik ut:

version: '3'
services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - ./wp-content:/var/www/html/wp-content
  db:
    image: mysql:5.7
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_ROOT_PASSWORD: somewordpress
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data:

Dette oppsettet er sårbart: WordPress-containeren kjører som root internt, har alle kapabiliteter (siden ingen er droppet), monterer en vertskatalog med skriveadgang, og har ubegrenset nettverkstilgang.

La oss nå herde det:

version: '3'
services:
  wordpress:
    image: wordpress:latest
    user: www-data
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    read_only: true
    tmpfs:
      - /var/www/html/wp-content/plugins
    security_opt:
      - seccomp=seccomp-profile.json
      - apparmor=wordpress-profile
    networks:
      - frontend
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - wp-uploads:/var/www/html/wp-content/uploads
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 256M
  db:
    image: mysql:5.7
    user: mysql
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    networks:
      - backend
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_ROOT_PASSWORD: somewordpress
    volumes:
      - db_data:/var/lib/mysql
    deploy:
      resources:
        limits:
          cpus: '0.25'
          memory: 128M
networks:
  frontend:
    driver: bridge
    internal: false
  backend:
    driver: bridge
    internal: true
volumes:
  wp-uploads:
  db_data:

Viktige forbedringer:

• Begge containere kjører som ikke-root-brukere (www-data og mysql).
• Alle kapabiliteter er droppet, kun NET_BIND_SERVICE er lagt til.
• WordPress-filsystemet er skrivebeskyttet unntatt for en tmpfs-montering og et uploads-volum.
• Seccomp- og AppArmor-profiler er brukt (du må levere egendefinerte profiler).
• Separate nettverk isolerer web fra database, med database-nettverket internt.
• Ressursgrenser forhindrer ressursutarming.

For mer om WordPress-spesifikk Docker-herding, se Docker for WordPress: Hvorfor isolerte containere endrer alt.

Forbehold

• Bruker-navnerom-ommapping: Selv om det er kraftig, bryter det volummontering fordi den ommappede vertens UID ikke er den samme som containerens UID. Du må kanskje forhåndsopprette kataloger med riktige tillatelser eller bruke Docker-volumer med ommapping-støtte.
• Seccomp/AppArmor-profiler: Egendefinerte profiler krever forståelse av applikasjonens systemkall- og filtilgangsmønstre. Overdrevent restriktive profiler kan bryte funksjonalitet. Test grundig.
• Ytelse: Ytterligere sikkerhetslag som seccomp og AppArmor har minimal overhead, men ressursgrenser og skrivebeskyttede filsystemer kan påvirke skriveintensive applikasjoner.
• Orkestreringskompleksitet: I et flerleiemiljø kan administrasjon av Docker Compose-filer per leietaker bli uhåndterlig. Vurder å bruke et orkestreringsverktøy på høyere nivå som Kubernetes, men det introduserer sine egne sikkerhetshensyn.

Konklusjon

Container-escape er en reell trussel i flerleiet Docker-hosting, men det kan forhindres. Ved å forstå isolasjonsmekanismene og anvende dybdeforsvar – droppe kapabiliteter, kjøre som ikke-root, aktivere bruker-navnerom, seccomp, AppArmor, nettverkssegmentering og regelmessig bilde-skanning – kan du dramatisk redusere risikoen. Husk at Dockers standardinnstillinger ikke er produksjonsklare for flerleie-arbeidsmengder. Implementer disse trinnene i dag for å beskytte leietakerne dine og infrastrukturen din. For en omfattende oversikt over beste praksis for Docker-sikkerhet, se Sikring av dine webapplikasjoner med Docker: En praktisk guide til isolasjon og beste praksis.