Kaitse konteineri väljapääsu eest: praktiline juhend Dockeri isolatsiooni kohta mitme üürnikuga majutuses

Kokkuvõte

Docker-konteinerid jagavad hosti kerneli, muutes isolatsiooni kriitiliseks – eriti mitme üürnikuga majutuses, kus üks konteineri väljapääs võib ohustada kõiki üürnikke. Paljud arendajad eeldavad, et konteinerid on täiesti isoleeritud virtuaalmasinad, kuid tegelikkus on teistsugune. See artikkel selgitab Dockeri isolatsiooni (nimiruumid, cgroups) taga olevaid Linuxi kerneli funktsioone ja nendele ohtlikke rünnakute vektoreid. Siit saate teada praktilisi samme oma Dockeri seadistuse tugevdamiseks: privileegide piiramine, turvalise käitusaja kasutamine, kujutiste skannimine ja võrgu segmenteerimine. Järgides reaalmaailma näidet mitme üürnikuga WordPressi majutusteenuse pakkujast, näete, kuidas neid kaitsemeetmeid rakendada. Samuti käsitleme hoiatusi, nagu jõudluse kompromissid ja seccomp/AppArmori kasutamine. Eesmärk on anda teile tugev isolatsioonistrateegia, mis hoiab ära konteineri väljapääsud ja kaitseb teie üürnikke.

Sissejuhatus

Kui haldate mitme üürnikuga majutusplatvormi – olgu see siis jagatud WordPressi majutus, SaaS-rakendus või arenduskeskkonna teenus – on konteineri väljapääs õudusunenägu. Kerneli haavatavus või vale konfiguratsioon võib lasta ühel üürnikul oma konteinerist välja murda ja pääseda juurde teiste üürnike andmetele või hostile endale. Dockeri isolatsioon tugineb Linuxi kerneli funktsioonidele, nagu nimiruumid ja cgroups, kuid vaikeseaded on sageli ebapiisavad robustse turvalisuse tagamiseks. See artikkel juhendab teid rünnakute vektorite kaudu ja pakub tegevussamme oma Docker-konteinerite lukustamiseks, illustreerituna reaalmaailma mitme üürnikuga WordPressi näitega. Laiema ülevaate saamiseks tootmiskorraldusest vaadake meie juhendit Tootmiskõlblike konteinerrakenduste korraldamine.

Dockeri isolatsiooni mõistmine

Docker-konteinerid kasutavad protsessitaseme isolatsiooniks Linuxi nimiruume: PID-nimiruumid isoleerivad protsessipuud, võrgu-nimiruumid eraldavad võrguliidesed, paigaldus-nimiruumid isoleerivad failisüsteemi paigaldused ja kasutaja-nimiruumid võimaldavad konteineri juuri kaardistada volitamata hosti kasutajale. Juhtelemendid (cgroups) piiravad ressursikasutust, nagu CPU, mälu ja kettal I/O. Need funktsioonid koos loovad iga konteineri ümber „liivakasti“. Kuid erinevalt virtuaalmasinast, mis töötab eraldi kerneliga, jagavad konteinerid hosti kerneli. See tähendab, et kerneli haavatavust (nt CVE-2022-0492) saab ära kasutada, et murda välja konteineri nimiruumi isolatsioonist. Lisaks võivad valed konfiguratsioonid, nagu konteineri käitamine juurkasutajana konteineri sees, kõigi võimekuste andmine konteinerile või ebavajalike Linuxi võimekuste mitte mahakandmine, laiendada rünnakupinda.

Rünnakute vektorid

Levinumad rünnakute vektorid hõlmavad:

• Kerneli ekspluateerimine: hosti kerneli vea ärakasutamine hosti juurdepääsu saamiseks.
• Volitatud konteinerid: --privileged käitamine annab kõik võimekused ja möödub enamikust isolatsioonist.
• Võimekuste kuritarvitamine: Isegi ilma täieliku volitatud režiimita võib ohtlike võimekustega nagu CAP_SYS_ADMIN või CAP_NET_ADMIN konteiner paigaldada failisüsteeme või manipuleerida võrguseadetega.
• Ebakindlad kujutiste tavad: teadaolevate haavatavustega baaskujutiste kasutamine või ebavajalike tööriistade, nagu kompilaatorid või kest-tõlgid, lisamine.
• Jagatud paigaldus-nimiruumid: hosti kataloogide paigaldamine konteineritesse võib lubada väljapääsu, kui see pole ainult lugemiseks.

Praktilised turvameetmed

1. Käivitage konteinereid mitte-juurkasutajana

Vaikimisi käitab Docker konteinereid juurkasutajana konteineri sees. Kui ründaja saab konteineri sees juurdepääsu, on tal rohkem mõjuvõimu. Looge oma Dockerfile'is kasutaja ja kasutage USER direktiivi. Samuti vältige Docker Compose'is --user lipu kasutamist, et kaardistada volitamata hosti kasutajale, kui see on võimalik.

2. Kandke maha kõik võimekused ja lisage ainult vajalikud

Linuxi võimekused jaotavad superkasutaja õigused väiksemateks üksusteks. Docker Compose'is kasutage cap_drop: ALL ja seejärel cap_add ainult vajalikke (nt NET_BIND_SERVICE). Vältige ohtlikke võimekusi nagu SYS_ADMIN, NET_ADMIN, SYS_PTRACE.

3. Kasutage ainult lugemiseks juurfailisüsteemi

Määrake oma konteineri definitsioonis read_only: true. See takistab ründajatel konteineri failisüsteemi kirjutamist. Kui teie rakendus vajab ajutiste failide kirjutamist, paigaldage sinna tmpfs-maht.

4. Lubage kasutaja nimiruumi ümberkaardistamine

Kasutaja nimiruumi ümberkaardistamine kaardistab konteineri juurkasutaja mitte-juur hosti kasutajaks. See lisab isolatsioonikihi, sest isegi kui konteineri juur murrab välja, on neil ümberkaardistatud kasutaja õigused. Lubage see /etc/docker/daemon.json failis "userns-remap": "default" abil. Olge teadlik, et see võib muuta mahu õigused keerulisemaks. Lisateavet leiate Dockeri isolatsiooni valdamine turvalise ja tõhusa veebimajutuse jaoks.

5. Rakendage Seccomp ja AppArmor/AppArmori profiilid

Seccomp piirab süsteemikutseid, mida konteiner saab teha. Docker pakub vaikimisi seccomp profiili, mis blokeerib ohtlikud süsteemikutse. Samuti saate luua kohandatud profiile. Samamoodi pakub AppArmor (või SELinux) kohustuslikku juurdepääsukontrolli. Kasutage AppArmorit, et piirata oma konteiner minimaalse lubatud toimingute komplektiga. Turvaprofiili saab määrata Docker Compose'is security_opt kaudu.

6. Kasutage minimaalseid baaskujutisi ja skannige haavatavuste järgi

Valige väikesed kujutised nagu Alpine või Distroless, millel on väiksem rünnakupind. Skannige kujutisi regulaarselt tööriistadega nagu Docker Scout, Trivy või Clair. Integreerige skannimine oma CI/CD torujuhtmesse, et vältida haavatavate kujutiste kasutuselevõttu.

7. Võrgu segmenteerimine kohandatud sillavõrkudega

Looge iga üürniku või rakenduse kihi jaoks eraldi sillavõrgud. See piirab idast-läänesse liiklust. Docker Compose'is määrake võrgud ja isoleerige teenused. Kasutage internal: true, kui teenus ei vaja väljaminevat Interneti-juurdepääsu. Hostil olevad tulemüürireeglid piiravad täiendavalt konteineritevahelist liiklust.

8. Piirake ressursse cgroupidega

Määrake CPU ja mälu piirangud Docker Compose'is deploy.resources.limits abil. See takistab kompromiteeritud konteineril käivitada ressursi ammendamise rünnakut. Lisaks määrake peenemaks juhtimiseks kernel_memory ja memory_reservation.

Reaalmaailma näide: mitme üürnikuga WordPressi majutus Docker Compose'iga

Kujutage ette stsenaariumi, kus majutate mitut WordPressi saiti erinevatele klientidele, igaüks oma Docker-konteineris. Ebakindel seadistus võib välja näha järgmine:

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:

See seadistus on haavatav: WordPressi konteiner töötab sees juurkasutajana, omab kõiki võimekusi (kuna ühtegi ei ole maha kantud), paigaldab hosti kataloogi kirjutamisjuurdepääsuga ja omab piiramatut võrguühendust.

Nüüd tugevdame seda:

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:

Põhilised täiustused:

• Mõlemad konteinerid töötavad mitte-juurkasutajatena (www-data ja mysql).
• Kõik võimekused on maha kantud, lisatud on ainult NET_BIND_SERVICE.
• WordPressi failisüsteem on ainult lugemiseks, välja arvatud tmpfs-maht ja üleslaadimiste maht.
• Rakendatakse Seccomp ja AppArmori profiile (te peate esitama kohandatud profiilid).
• Eraldi võrgud isoleerivad veebi andmebaasist, andmebaasivõrk on sisemine.
• Ressursipiirangud takistavad ressursside ammendamist.

Lisateavet WordPressi spetsiifilise Dockeri tugevdamise kohta leiate artiklist Docker WordPressi jaoks: miks isoleeritud konteinerid muudavad kõike.

Hoiatused

• Kasutaja nimiruumi ümberkaardistamine: kuigi võimas, rikub see mahu paigaldamist, kuna ümberkaardistatud hosti UID ei ole sama mis konteineri UID. Võimalik, et peate katalooge eelnevalt õigete õigustega looma või kasutama ümberkaardistamise tuge pakkuvaid Docker-mahte.
• Seccomp/AppArmori profiilid: kohandatud profiilid nõuavad teie rakenduse süsteemikutsete ja faili juurdepääsumustrite mõistmist. Liiga piiravad profiilid võivad funktsionaalsust rikkuda. Testige põhjalikult.
• Jõudlus: täiendavad turvakihid, nagu seccomp ja AppArmor, on minimaalse ülekoormusega, kuid ressursipiirangud ja ainult lugemiseks mõeldud failisüsteemid võivad mõjutada kirjutamispõhiseid rakendusi.
• Korralduskompleksus: mitme üürnikuga keskkonnas võib üürnikupõhiste Docker Compose failide haldamine muutuda tülikaks. Kaaluge kõrgema taseme korraldustööriista, nagu Kubernetes, kasutamist, kuid see toob kaasa oma turvakaalutlused.

Järeldus

Konteineri väljapääs on mitme üürnikuga Docker-majutuses reaalne oht, kuid seda saab ennetada. Isolatsioonimehhanismide mõistmise ja kaitse-kihtide rakendamise abil – võimekuste mahakandmine, mitte-juurkasutajana töötamine, kasutaja nimiruumide lubamine, seccomp, AppArmor, võrgu segmenteerimine ja regulaarne kujutiste skannimine – saate riski oluliselt vähendada. Pidage meeles, et Dockeri vaikeseaded ei ole tootmiskõlblikud mitme üürnikuga töökoormuste jaoks. Rakendage need sammud juba täna, et kaitsta oma üürnikke ja infrastruktuuri. Laiema ülevaate saamiseks Dockeri turvalisuse parimatest tavadest vaadake Veebirakenduste turvamine Dockeriga: praktiline juhend isolatsiooni ja parimate tavade kohta.