Odbrana od bijega iz kontejnera: Praktični vodič za Docker izolaciju za hosting više zakupaca

Sažetak

Docker kontejneri dijele kernel hosta, što čini izolaciju kritičnom—posebno u hostingu više zakupaca gdje jedan bijeg iz kontejnera može ugroziti sve zakupce. Mnogi programeri pretpostavljaju da su kontejneri savršeno izolirane virtualne mašine, ali stvarnost je drugačija. Ovaj članak objašnjava karakteristike Linux kernela koje stoje iza Docker izolacije (namespaces, cgroups) i vektore napada koji ih ugrožavaju. Naučit ćete praktične korake za jačanje vašeg Docker podešavanja: ograničavanje privilegija, korištenje sigurnog runtime-a, skeniranje slika i implementaciju mrežne segmentacije. Prateći primjer iz stvarnog svijeta provajdera hostinga za WordPress s više zakupaca, vidjet ćete kako primijeniti ove odbrane. Također pokrivamo napomene poput kompromisa u performansama i korištenja seccomp/AppArmor. Cilj je dati vam robusnu strategiju izolacije koja sprječava bijeg iz kontejnera i čuva vaše zakupce na sigurnom.

Uvod

Ako vodite platformu za hosting više zakupaca—bilo da se radi o dijeljenom hostingu za WordPress, SaaS aplikaciji ili usluzi razvojnog okruženja—bijeg iz kontejnera je noćna mora. Ranjivost u kernelu ili pogrešna konfiguracija može omogućiti jednom zakupcu da se izvuče iz svog kontejnera i pristupi podacima drugih zakupaca ili samom hostu. Dockerova izolacija se oslanja na karakteristike Linux kernela kao što su namespaces i cgroups, ali fabrička podešavanja često nisu dovoljna za robusnu sigurnost. Ovaj članak će vas provesti kroz vektore napada i pružiti primjenjive korake za zaključavanje vaših Docker kontejnera, ilustrovano primjerom WordPress hostinga za više zakupaca iz stvarnog svijeta. Za širi pogled na produkcijsku orkestraciju, pogledajte naš vodič o Orkestriranje produkcijski spremnih kontejnerizovanih aplikacija.

Razumijevanje Docker izolacije

Docker kontejneri koriste Linux namespaces za pružanje izolacije na nivou procesa: PID namespaces izoluju stabla procesa, network namespaces odvajaju mrežne interfejse, mount namespaces izoluju sisteme datoteka, a user namespaces omogućavaju mapiranje root korisnika kontejnera na neprivilegovanog korisnika hosta. Kontrolne grupe (cgroups) ograničavaju korištenje resursa kao što su CPU, memorija i I/O diska. Ove karakteristike zajedno stvaraju "sandbox" oko svakog kontejnera. Međutim, za razliku od virtualne mašine koja pokreće odvojeni kernel, kontejneri dijele kernel hosta. To znači da se ranjivost u kernelu (npr. CVE-2022-0492) može iskoristiti za bijeg iz izolacije namespace-a kontejnera. Dodatno, pogrešne konfiguracije kao što je pokretanje kontejnera kao root unutar kontejnera, davanje svih mogućnosti kontejneru, ili neodbacivanje nepotrebnih Linux mogućnosti mogu proširiti površinu napada.

Vektori napada

Uobičajeni vektori napada uključuju:

• Iskorištavanje kernela: Iskoristite grešku u kernelu hosta da biste dobili pristup hostu.
• Privilegovani kontejneri: Pokretanje s --privileged daje sve mogućnosti i zaobilazi većinu izolacije.
• Zloupotreba mogućnosti: Čak i bez punog privilegovanog načina rada, kontejner s opasnim mogućnostima kao što su CAP_SYS_ADMIN ili CAP_NET_ADMIN može montirati sisteme datoteka ili manipulirati mrežnim postavkama.
• Nesigurne prakse slika: Korištenje osnovnih slika s poznatim ranjivostima ili uključivanje nepotrebnih alata kao što su kompajleri ili interpretatori ljuske.
• Zajednički mount namespaces: Montiranje direktorija hosta u kontejnere može omogućiti bijeg ako nije samo za čitanje.

Praktični sigurnosni koraci

1. Pokrenite kontejnere kao korisnik koji nije root

Podrazumevano, Docker pokreće kontejnere kao root unutar kontejnera. Ako napadač dobije root pristup unutar kontejnera, ima više poluga. Kreirajte korisnika u vašem Dockerfile-u i koristite USER direktivu. Također, izbjegavajte korištenje --user zastavice u Docker Compose-u za mapiranje na proizvoljnog korisnika hosta ako je moguće.

2. Odbacite sve mogućnosti i dodajte samo potrebne

Linux mogućnosti razbijaju privilegije superkorisnika na manje jedinice. U Docker Compose-u, koristite cap_drop: ALL, a zatim cap_add samo potrebne (npr. NET_BIND_SERVICE). Izbjegavajte opasne mogućnosti kao što su SYS_ADMIN, NET_ADMIN, SYS_PTRACE.

3. Koristite root datotečni sistem samo za čitanje

Podesite read_only: true u definiciji vašeg kontejnera. Ovo sprječava napadače da pišu u datotečni sistem kontejnera. Ako vaša aplikacija treba pisati privremene datoteke, montirajte tmpfs volumen na toj lokaciji.

4. Omogućite ponovno mapiranje korisničkih imena (User Namespace Remapping)

Povratno mapiranje korisničkih imena mapira root korisnika kontejnera na neprivilegovanog korisnika hosta. Ovo dodaje sloj izolacije, jer čak i ako se root kontejnera izvuče, imat će privilegije mapiranog korisnika. Omogućite ga u /etc/docker/daemon.json sa "userns-remap": "default". Imajte na umu da ovo može zakomplicirati dozvole za volumen. Za više detalja, pogledajte Ovladavanje Docker izolacijom za siguran i efikasan web hosting.

5. Primijenite Seccomp i AppArmor/AppArmor profile

Seccomp ograničava sistemske pozive koje kontejner može napraviti. Docker pruža fabrički seccomp profil koji blokira opasne sistemske pozive. Također možete kreirati prilagođene profile. Slično, AppArmor (ili SELinux) pruža obaveznu kontrolu pristupa. Koristite AppArmor da ograničite vaš kontejner na minimalan skup dozvoljenih operacija. Sigurnosni profil se može postaviti putem security_opt u Docker Compose-u.

6. Koristite minimalne osnovne slike i skenirajte na ranjivosti

Odaberite male slike kao što su Alpine ili Distroless koje imaju manju površinu napada. Redovno skenirajte slike alatima kao što su Docker Scout, Trivy ili Clair. Integrirajte skeniranje u vaš CI/CD pipeline kako biste spriječili postavljanje ranjivih slika.

7. Mrežna segmentacija s prilagođenim bridge mrežama

Kreirajte odvojene bridge mreže za svakog zakupca ili sloj aplikacije. Ovo ograničava promet od istoka prema zapadu. U Docker Compose-u, definirajte mreže i izolujte servise. Koristite internal: true ako servis ne treba izlazni pristup internetu. Firewall pravila na hostu dodatno ograničavaju promet između kontejnera.

8. Ograničite resurse pomoću cgroups

Podesite ograničenja CPU-a i memorije u Docker Compose-u pomoću deploy.resources.limits. Ovo sprječava kompromitovani kontejner da pokrene napad iscrpljivanja resursa. Dodatno, podesite kernel_memory i memory_reservation za finije podešavanje.

Primjer iz stvarnog svijeta: WordPress hosting za više zakupaca s Docker Compose-om

Razmotrite scenarij u kojem hostujete više WordPress sajtova za različite klijente, svaki u svom Docker kontejneru. Nesiguran setup bi mogao izgledati ovako:

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:

Ovaj setup je ranjiv: WordPress kontejner radi kao root unutra, ima sve mogućnosti (jer nijedna nije odbačena), montira direktorij hosta s pristupom pisanju i ima neograničen mrežni pristup.

Sada ga pojačajmo:

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:

Ključna poboljšanja:

• Oba kontejnera rade kao korisnici koji nisu root (www-data i mysql).
• Sve mogućnosti su odbačene, dodana je samo NET_BIND_SERVICE.
• WordPress datotečni sistem je samo za čitanje osim tmpfs mounta i volumena za upload.
• Primijenjeni su seccomp i AppArmor profili (morali biste dostaviti prilagođene profile).
• Odvojene mreže izoluju web od baze podataka, s internom mrežom za bazu podataka.
• Ograničenja resursa sprječavaju iscrpljivanje resursa.

Više o Docker hardeningu specifičnom za WordPress, pogledajte Docker za WordPress: Zašto izolovani kontejneri mijenjaju sve.

Napomene

• Ponovno mapiranje korisničkih imena (User Namespace Remapping): Iako moćno, ono prekida montiranje volumena jer ponovno mapirani UID hosta nije isti kao UID kontejnera. Možda ćete morati unaprijed kreirati direktorije s ispravnim dozvolama ili koristiti Docker volumene s podrškom za ponovno mapiranje.
• Seccomp/AppArmor profili: Prilagođeni profili zahtijevaju razumijevanje obrazaca sistemskih poziva i pristupa datotekama vaše aplikacije. Previše restriktivni profili mogu narušiti funkcionalnost. Testirajte temeljito.
• Performanse: Dodatni sigurnosni slojevi kao što su seccomp i AppArmor imaju minimalan dodatni trošak, ali ograničenja resursa i datotečni sistemi samo za čitanje mogu utjecati na aplikacije koje intenzivno pišu.
• Složenost orkestracije: U okruženju s više zakupaca, upravljanje Docker Compose datotekama po zakupcu može postati nezgrapno. Razmotrite korištenje alata za orkestraciju višeg nivoa kao što je Kubernetes, ali to uvodi vlastite sigurnosne razmatranja.

Zaključak

Bijeg iz kontejnera je stvarna prijetnja u Docker hostingu za više zakupaca, ali se može spriječiti. Razumijevanjem mehanizama izolacije i primjenom odbrane u dubinu—odbacivanjem mogućnosti, pokretanjem kao korisnik koji nije root, omogućavanjem korisničkih imena, seccomp-a, AppArmor-a, mrežne segmentacije i redovnog skeniranja slika—možete dramatično smanjiti rizik. Zapamtite da podrazumevana podešavanja Dockera nisu spremna za produkciju za radna opterećenja s više zakupaca. Implementirajte ove korake danas kako biste zaštitili svoje zakupce i svoju infrastrukturu. Za sveobuhvatan pregled najboljih praksi za sigurnost Dockera, pogledajte Osiguravanje vaših web aplikacija pomoću Dockera: Praktični vodič za izolaciju i najbolje prakse.