Blogg

En praktisk Docker-isolasjonssikkerhetssjekkliste for flerleievert hosting

Sikre ditt flerleie Docker-hosting med denne praktiske sjekklisten som dekker ikke-root-brukere, kapabiliteter, seccomp, brukernavnerom, ressursgrenser og skrivebeskyttede filsystemer.

Oppsummering

Flerleie Docker-hosting krever sterk isolasjon for å forhindre container-utbrudd. Denne artikkelen gir en praktisk sikkerhetssjekkliste som dekker seks nøkkelområder: kjør som ikke-root, slipp kapabiliteter, bruk seccomp-profiler, aktiver omkartlegging av brukernavnerom, sett ressursgrenser, og bruk skrivebeskyttede rotfilsystemer. Hvert trinn inkluderer et konkret konfigurasjonseksempel for Docker Compose. Du vil også lære vanlige fallgruver som kjernekompatibilitetsproblemer med brukernavnerom og ytelsesavveininger ved bruk av seccomp. Ved å følge denne sjekklisten kan du betydelig redusere angrepsoverflaten uten å legge til unødvendig kompleksitet. Artikkelen avsluttes med en anbefalt grunnkonfigurasjon for produksjonsmiljøer med flerleie.

Hvis du kjører et flerleie Docker-miljø, holder spøkelset av et container-utbruddsangrep deg våken om natten. Ett kjerneeksploit kan bryte ut av en container og gi en angriper ubegrenset tilgang til verten og alle andre leietakeres data. Mens Docker gir kraftige isolasjonsprimitiver—navnerom, cgroups og kapabiliteter—etterlater feilkonfigurasjon hull. Denne artikkelen presenterer en trinnvis sikkerhetssjekkliste du kan bruke i dag. Hvert trinn inkluderer et fungerende Docker Compose-utdrag og viktige forbehold. Ved slutten vil du ha en herdet grunnlinje som balanserer sikkerhet og ytelse.

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

Containere kjører som standard som root inne i containeren. Hvis en angriper får root i containeren, har de et forsprang på å rømme. Definer alltid en ikke-root-bruker i Dockerfilen din.

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

I Compose kan du også sette brukeren direkte:

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

Forbehold: Noen applikasjoner krever root for legitime operasjoner (f.eks. binding til porter under 1024). Bruk CAP_NET_BIND_SERVICE i stedet for å kjøre hele containeren som root. For en dypere titt på isolasjonsgrunnlag, se vår guide om å oppnå ekte flerleie-isolasjon i Docker.

2. Slipp alle kapabiliteter og legg til bare det som trengs

Linux-kapabiliteter gir containere finkornede privilegier. Som standard gir Docker et sett med kapabiliteter. Slipp alt og gi bare de som kreves.

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

Forbehold: Kapabiliteter som SYS_ADMIN eller NET_RAW er sjelden nødvendige. Gjennomgå applikasjonen din for å bestemme minimumssettet. Å slippe alle kapabiliteter blokkerer mange rømningsvektorer.

3. Bruk en seccomp-profil

Seccomp (secure computing mode) filtrerer systemkall tilgjengelig for en container. Docker leveres med en standard seccomp-profil som blokkerer farlige systemkall som clone med visse flagg. Du kan tilpasse den ytterligere.

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

En herdet profil kan blokkere unshare, ptrace og mount. Start med Dockets standard og begrens mer. Forbehold: Altfor strenge profiler kan ødelegge applikasjoner. Test grundig i et staging-miljø. For mer om container-utbruddsforsvar, les forsvare mot container-utbrudd.

4. Aktiver omkartlegging av brukernavnerom

Brukernavnerom kartlegger containerens root-bruker til en uprivilegert vertsbruker. Dette betyr at selv om en angriper får root inne i containeren, har de ingen spesielle privilegier på verten.

Aktiver det på Docker-demonen ved å redigere /etc/docker/daemon.json:

{
  "userns-remap": "default"
}

Start deretter Docker på nytt. Forbehold: Omkartlegging av brukernavnerom har to ulemper: det bryter volummounts når det ikke er konfigurert nøye (filer eies av den omkartlagte brukeren) og er inkompatibelt med enkelte lagringdrivere som overlay2 på eldre kjerner. Test grundig.

5. Sett ressursgrenser med cgroups

Ressursgrenser forhindrer en kompromittert container fra å starte et tjenestenektangrep mot verten. Bruk cgroups til å begrense CPU, minne og disk I/O.

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

For Docker Compose v3, bruk deploy-delen (fungerer med swarm eller compose v2). For vanlig Docker, bruk --memory og --cpus. Forbehold: Å sette grenser for lavt kan føre til OOM-drap. Overvåk bruk og juster deretter.

6. Bruk skrivebeskyttet rotfilsystem

Et skrivebeskyttet rotfilsystem forhindrer angripere fra å skrive ondsinnede binærfiler eller endre konfigurasjonsfiler inne i containeren.

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

Monter tmpfs på kataloger som trenger skrivetilgang (som /tmp). Dette tvinger alle skrivbare data til å være flyktige. Forbehold: Noen applikasjoner krever vedvarende lagring; bruk navngitte volumer for det.

Vanlige fallgruver

  • Kjernekompatibilitet: Omkartlegging av brukernavnerom og noen seccomp-regler krever en ny Linux-kjerne (4.14+). Sjekk kjerneversjonen din.
  • Ytelsespåvirkning: Seccomp og brukernavnerom legger til en liten overhead, men den er ubetydelig for de fleste arbeidsbelastninger. Benchmark din spesifikke app.
  • Kompleksitet: Å legge til alle seks tiltak på en gang kan bryte ting. Bruk dem én etter én, test hver endring.

For en bredere oversikt over orkestreringsmønstre, se vår guide om design av en flerleie Docker-arkitektur.

Konklusjon

En sikker flerleie Docker-vert krever ikke eksotiske verktøy—bare riktig bruk av Dockets innebygde funksjoner. Start med en ikke-root-bruker, slipp alle kapabiliteter, bruk en seccomp-profil, aktiver omkartlegging av brukernavnerom, sett ressursgrenser, og bruk et skrivebeskyttet filsystem. Denne sjekklisten danner en sterk grunnlinje som blokkerer de vanligste rømningsteknikkene. Etter implementeringen, kjør sikkerhetsverktøy som docker-bench-security for å verifisere konfigurasjonen din. Husk: sikkerhet er en prosess, ikke et produkt. Etter hvert som nye kjerne-sårbarheter dukker opp, se over innstillingene dine. For automatiserte landingssider som viser frem vertstjenesten din, bruk Pagenza for å få nettstedet ditt live på minutter.

Sources (5)