En praktisk Docker-isoleringssikkerhedstjekliste til multi-tenant hosting

Resumé

Multi-tenant Docker-hosting kræver stærk isolation for at forhindre container-udbrud. Denne artikel giver en praktisk sikkerhedstjekliste, der dækker seks nøgleområder: kør som ikke-root, fjern capabilities, anvend seccomp-profiler, aktiver user namespace-omapning, sæt ressourcegrænser, og brug skrivebeskyttede root-filsystemer. Hvert trin inkluderer et konkret konfigurationseksempel til Docker Compose. Du vil også lære om almindelige faldgruber som kernelkompatibilitetsproblemer med user namespaces og ydeevneafvejninger ved anvendelse af seccomp. Ved at følge denne tjekliste kan du markant reducere angrebsfladen uden at tilføje unødvendig kompleksitet. Artiklen afsluttes med en anbefalet basiskonfiguration til produktionsmiljøer med flere lejere.

Hvis du driver et multi-tenant Docker-miljø, holder spøgelset af et container-udbrudsangreb dig vågen om natten. Et enkelt kernel-udnyttelse kan bryde ud af en container og give en angriber ubegrænset adgang til værten og alle andre tenanters data. Mens Docker tilbyder kraftfulde isolationsprimitiver—namespaces, cgroups og capabilities—efterlader fejlkonfiguration huller. Denne artikel præsenterer en trin-for-trin sikkerhedstjekliste, som du kan anvende i dag. Hvert trin inkluderer et fungerende Docker Compose-uddrag og vigtige forbehold. Ved slutningen har du en hærdet basislinje, der balancerer sikkerhed og ydeevne.

1. Kør containere som en ikke-root-bruger

Containere kører som standard som root inde i containeren. Hvis en angriber får root-adgang i containeren, har de et forspring til at undslippe. Definer altid en ikke-root-bruger i din Dockerfile.

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

I Compose kan du også indstille brugeren direkte:

services:
  app:
    image: myapp
    user: "1000:1000"

Caveat: Nogle applikationer kræver root til legitime operationer (f.eks. binding til porte under 1024). Brug CAP_NET_BIND_SERVICE i stedet for at køre hele containeren som root. For en dybere indsigt i isolationsgrundlag, se vores guide om opnå ægte multi-tenant isolation i Docker.

2. Fjern alle capabilities og tilføj kun dem, der er nødvendige

Linux-capabilities giver containere finkornede privilegier. Som standard tildeler Docker et sæt capabilities. Fjern alt, og tildel kun dem, der er nødvendige.

services:
  app:
    image: myapp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # if needed

Caveat: Capabilities som SYS_ADMIN eller NET_RAW er sjældent nødvendige. Gennemgå din applikation for at bestemme det minimale sæt. At fjerne alle capabilities blokerer mange undslippelsesvektorer.

3. Anvend en seccomp-profil

Seccomp (secure computing mode) filtrerer systemkald, der er tilgængelige for en container. Docker leveres med en standard seccomp-profil, der blokerer farlige syscalls som clone med bestemte flag. Du kan tilpasse den yderligere.

services:
  app:
    image: myapp
    security_opt:
      - seccomp=/path/to/custom-profile.json

En hærdet profil kunne blokere unshare, ptrace og mount. Start med Dockets standard og begræns mere. Caveat: For strenge profiler kan ødelægge applikationer. Test grundigt i et staging-miljø. For mere om forsvar mod container-udbrud, læs forsvar mod container-udbrud.

4. Aktiver user namespace-omapning

User namespaces kortlægger containerens root-bruger til en uprivilegeret værtsbruger. Det betyder, at selvom en angriber får root-adgang inde i containeren, har de ingen særlige privilegier på værten.

Aktiver det på Docker-dæmonen ved at redigere /etc/docker/daemon.json:

{
  "userns-remap": "default"
}

Genstart derefter Docker. Caveat: User namespace-omapning har to ulemper: det ødelægger volumenmonteringer, når det ikke konfigureres omhyggeligt (filer ejes af den omappede bruger) og er inkompatibelt med nogle lagerdrivere som overlay2 på ældre kerner. Test grundigt.

5. Sæt ressourcegrænser med cgroups

Ressourcegrænser forhindrer en kompromitteret container i at iværksætte et denial-of-service-angreb mod værten. Brug cgroups til at begrænse CPU, hukommelse og disk I/O.

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

Til Docker Compose v3, brug sektionen deploy (fungerer med swarm eller compose v2). Til almindelig Docker, brug --memory og --cpus. Caveat: At sætte grænser for lavt kan forårsage OOM-dræb. Overvåg brug og juster derefter.

6. Brug skrivebeskyttet root-filsystem

Et skrivebeskyttet root-filsystem forhindrer angribere i at skrive ondsindede binære filer eller ændre konfigurationsfiler inde i containeren.

services:
  app:
    image: myapp
    read_only: true
    tmpfs:
      - /tmp:noexec,nosuid,size=64m

Monter tmpfs på mapper, der har brug for skriveadgang (som /tmp). Dette tvinger alle skrivbare data til at være flygtige. Caveat: Nogle applikationer kræver vedvarende opbevaring; brug navngivne volumener til det.

Almindelige faldgruber

• Kernelkompatibilitet: User namespace-omapning og nogle seccomp-regler kræver en ny Linux-kerne (4.14+). Tjek din kerneversion.
• Ydeevnepåvirkning: Seccomp og user namespaces tilføjer en lille overhead, men det er ubetydeligt for de fleste arbejdsbelastninger. Benchmark din specifikke app.
• Kompleksitet: At tilføje alle seks foranstaltninger på én gang kan ødelægge ting. Anvend dem én ad gangen, test hver ændring.

For en bredere oversigt over orkestreringsmønstre, se vores guide om design af en multi-tenant Docker-arkitektur.

Konklusion

En sikker multi-tenant Docker-vært kræver ikke eksotiske værktøjer—bare korrekt brug af Dockets indbyggede funktioner. Start med en ikke-root-bruger, fjern alle capabilities, anvend en seccomp-profil, aktiver user namespace-omapning, sæt ressourcegrænser, og brug et skrivebeskyttet filsystem. Denne tjekliste udgør en stærk basislinje, der blokerer de mest almindelige undslippelsesteknikker. Efter implementering, kør sikkerhedsværktøjer som docker-bench-security for at verificere din konfiguration. Husk: sikkerhed er en proces, ikke et produkt. Når nye kernel-sårbarheder opstår, gennemgå dine indstillinger. For automatiserede landingssider, der fremviser din hostingtjeneste, brug Pagenza til at få din side live på få minutter.