Aizsardzība pret konteineru aizbēgšanu: Praktiskā rokasgrāmata par Docker izolāciju vairākām īrētāju mitināšanai

Kopsavilkums

Docker konteineri koplieto resursdatora kodolu, padarot izolāciju kritiski svarīgu — īpaši vairāku īrētāju mitināšanā, kur viena konteinera aizbēgšana var apdraudēt visus īrētājus. Daudzi izstrādātāji pieņem, ka konteineri ir pilnībā izolētas virtuālās mašīnas, taču realitāte ir citāda. Šis raksts skaidro Linux kodola funkcijas, kas nodrošina Docker izolāciju (vārdu telpas, cgroups), un uzbrukumu vektorus, kas tās apdraud. Jūs uzzināsiet praktiskus soļus, kā uzlabot savu Docker iestatījumu: ierobežot privilēģijas, izmantot drošu izpildlaiku, skenēt attēlus un ieviest tīkla segmentāciju. Sekojot reālās pasaules piemēram par vairāku īrētāju WordPress mitināšanas nodrošinātāju, jūs redzēsiet, kā piemērot šīs aizsardzības. Mēs arī aplūkosim iebildumus, piemēram, veiktspējas kompromisus un seccomp/AppArmor izmantošanu. Mērķis ir sniegt jums spēcīgu izolācijas stratēģiju, kas novērš konteineru aizbēgšanu un nodrošina jūsu īrētāju drošību.

Ievads

Ja jūs vadāt vairāku īrētāju mitināšanas platformu — neatkarīgi no tā, vai tā ir koplietota WordPress mitināšana, SaaS lietojumprogramma vai izstrādes vides pakalpojums — konteinera aizbēgšana ir murgs. Kodola ievainojamība vai nepareiza konfigurācija var ļaut vienam īrētājam izlauzties no sava konteinera un piekļūt citu īrētāju datiem vai pašam resursdatoram. Docker izolācija paļaujas uz Linux kodola funkcijām, piemēram, vārdu telpām un cgroups, taču noklusējuma konfigurācijas bieži vien nav pietiekamas spēcīgai drošībai. Šis raksts iepazīstinās jūs ar uzbrukumu vektoriem un sniegs praktiskus soļus, lai bloķētu jūsu Docker konteinerus, ilustrējot to ar reālās pasaules vairāku īrētāju WordPress piemēru. Lai iegūtu plašāku ieskatu par ražošanas orķestrēšanu, skatiet mūsu ceļvedi par Orķestrēšana ražošanai gatavām konteinerizētām lietojumprogrammām.

Docker izolācijas izpratne

Docker konteineri izmanto Linux vārdu telpas, lai nodrošinātu procesu līmeņa izolāciju: PID vārdu telpas izolē procesu kokus, tīkla vārdu telpas atdala tīkla saskarnes, montāžas vārdu telpas izolē failu sistēmas montāžas, un lietotāju vārdu telpas ļauj kartēt konteinera sakni uz nepriviliģētu resursdatora lietotāju. Kontrolgrupas (cgroups) ierobežo resursu izmantošanu, piemēram, CPU, atmiņu un diska I/O. Šīs funkcijas kopā izveido “smilškasti” ap katru konteineri. Tomēr, atšķirībā no virtuālās mašīnas, kas darbojas ar atsevišķu kodolu, konteineri koplieto resursdatora kodolu. Tas nozīmē, ka kodola ievainojamību (piemēram, CVE-2022-0492) var izmantot, lai izlauztos no konteinera vārdu telpas izolācijas. Turklāt nepareizas konfigurācijas, piemēram, konteineru palaišana kā root konteinera iekšienē, piešķirot konteinerim visas iespējas vai nenometot nevajadzīgas Linux iespējas, var paplašināt uzbrukuma virsmu.

Uzbrukumu vektori

Izplatīti uzbrukumu vektori ietver:

• Kodola ekspluatācijas: Resursdatora kodola kļūdas izmantošana, lai iegūtu piekļuvi resursdatoram.
• Priviliģēti konteineri: Palaist ar --privileged piešķir visas iespējas un apiet lielāko daļu izolācijas.
• Iespēju ļaunprātīga izmantošana: Pat bez pilna privilēģiju režīma, konteiners ar bīstamām iespējām, piemēram, CAP_SYS_ADMIN vai CAP_NET_ADMIN, var montēt failu sistēmas vai manipulēt ar tīkla iestatījumiem.
• Nenodrošinātas attēlu prakses: Izmantojot bāzes attēlus ar zināmām ievainojamībām vai iekļaujot nevajadzīgus rīkus, piemēram, kompilatorus vai apvalka interpretētājus.
• Koplietotas montāžas vārdu telpas: Resursdatora direktoriju montāža konteineros var pieļaut aizbēgšanu, ja tie nav tikai lasāmi.

Praktiski drošības soļi

1. Palaidiet konteinerus kā ne-root lietotājs

Pēc noklusējuma Docker palaida konteinerus kā root konteinera iekšienē. Ja uzbrucējs iegūst root piekļuvi konteinera iekšienē, viņam ir vairāk iespēju. Izveidojiet lietotāju savā Dockerfile un izmantojiet USER direktīvu. Tāpat izvairieties izmantot --user karodziņu Docker Compose, lai kartētu uz patvaļīgu resursdatora lietotāju, ja tas ir iespējams.

2. Nometiet visas iespējas un pievienojiet tikai nepieciešamās

Linux iespējas sadala superlietotāja privilēģijas mazākos vienumos. Docker Compose izmantojiet cap_drop: ALL, pēc tam cap_add tikai nepieciešamās (piemēram, NET_BIND_SERVICE). Izvairieties no bīstamām iespējām, piemēram, SYS_ADMIN, NET_ADMIN, SYS_PTRACE.

3. Izmantojiet tikai lasāmu saknes failu sistēmu

Iestatiet read_only: true savā konteinera definīcijā. Tas neļauj uzbrucējiem rakstīt konteinera failu sistēmā. Ja jūsu lietotnei ir nepieciešams rakstīt pagaidu failus, pievienojiet tmpfs apjomu šajā vietā.

4. Iespējojiet lietotāju vārdu telpas pārmapēšanu

Lietotāju vārdu telpas pārmapēšana kartē konteinera root lietotāju uz ne-root resursdatora lietotāju. Tas pievieno izolācijas slāni, jo pat ja konteinera root izlaužas, viņiem būs pārmapītā lietotāja privilēģijas. Iespējojiet to /etc/docker/daemon.json ar "userns-remap": "default". Ņemiet vērā, ka tas var sarežģīt apjomu atļaujas. Lai iegūtu vairāk informācijas, skatiet Docker izolācijas apgūšana drošai un efektīvai tīmekļa mitināšanai.

5. Lietojiet Seccomp un AppArmor/AppArmor profilus

Seccomp ierobežo sistēmas izsaukumus, ko konteiners var veikt. Docker nodrošina noklusējuma seccomp profilu, kas bloķē bīstamus sistēmas izsaukumus. Jūs varat arī izveidot pielāgotus profilus. Līdzīgi AppArmor (vai SELinux) nodrošina obligātu piekļuves kontroli. Izmantojiet AppArmor, lai ierobežotu savu konteineru līdz minimālam atļauto operāciju kopumam. Drošības profilu var iestatīt, izmantojot security_opt Docker Compose.

6. Izmantojiet minimālos bāzes attēlus un skenējiet pēc ievainojamībām

Izvēlieties mazus attēlus, piemēram, Alpine vai Distroless, kuriem ir mazāka uzbrukuma virsma. Regulāri skenējiet attēlus ar rīkiem, piemēram, Docker Scout, Trivy vai Clair. Integrējiet skenēšanu savā CI/CD cauruļvadā, lai novērstu neaizsargātu attēlu izvietošanu.

7. Tīkla segmentācija ar pielāgotiem tilta tīkliem

Izveidojiet atsevišķus tilta tīklus katram īrētājam vai lietojumprogrammas līmenim. Tas ierobežo satiksmi uz austrumiem un rietumiem. Docker Compose definējiet tīklus un izolējiet pakalpojumus. Izmantojiet internal: true, ja pakalpojumam nav nepieciešama piekļuve internetam. Ugunsmūra noteikumi resursdatorā vēl vairāk ierobežo satiksmi starp konteineriem.

8. Ierobežojiet resursus ar Cgroups

Iestatiet CPU un atmiņas ierobežojumus Docker Compose, izmantojot deploy.resources.limits. Tas novērš kompromitēta konteinera palaišanu resursu izsīkšanas uzbrukumu. Turklāt iestatiet kernel_memory un memory_reservation precīzākai kontrolei.

Reālās pasaules piemērs: Vairāku īrētāju WordPress mitināšana ar Docker Compose

Apsveriet scenāriju, kurā jūs mitināt vairākas WordPress vietnes dažādiem klientiem, katru savā Docker konteinerī. Nenodrošināta iestatīšana varētu izskatīties šādi:

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:

Šis iestatījums ir neaizsargāts: WordPress konteiners darbojas kā root iekšienē, tam ir visas iespējas (tā kā neviena nav nometta), tas montē resursdatora direktoriju ar rakstīšanas piekļuvi un tam ir neierobežota piekļuve tīklam.

Tagad to uzlabosim:

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:

Galvenie uzlabojumi:

• Abi konteineri darbojas kā ne-root lietotāji (www-data un mysql).
• Visas iespējas nometas, pievienota tikai NET_BIND_SERVICE.
• WordPress failu sistēma ir tikai lasāma, izņemot tmpfs montāžu un augšupielāžu apjomu.
• Tiek lietoti Seccomp un AppArmor profili (jums būtu jāsniedz pielāgoti profili).
• Atsevišķi tīkli izolē tīmekli no datubāzes, datubāzes tīklam esot iekšējam.
• Resursu ierobežojumi novērš resursu izsīkšanu.

Lai uzzinātu vairāk par WordPress specifisko Docker uzlabošanu, skatiet Docker WordPress: Kāpēc izolēti konteineri maina visu.

Iebildumi

• Lietotāju vārdu telpas pārmapēšana: Lai gan tā ir spēcīga, tā pārtrauc apjomu montāžu, jo pārmapītais resursdatora UID nav tāds pats kā konteinera UID. Iespējams, jums būs iepriekš jāizveido direktoriji ar pareizām atļaujām vai jāizmanto Docker apjomi ar pārmapīšanas atbalstu.
• Seccomp/AppArmor profili: Pielāgoti profili prasa izprast jūsu lietojumprogrammas sistēmas izsaukumu un failu piekļuves modeļus. Pārāk ierobežojoši profili var pārtraukt funkcionalitāti. Pārbaudiet rūpīgi.
• Veiktspēja: Papildu drošības slāņi, piemēram, seccomp un AppArmor, rada minimālu papildu slodzi, taču resursu ierobežojumi un tikai lasāmas failu sistēmas var ietekmēt lietojumprogrammas, kas daudz raksta.
• Orķestrēšanas sarežģītība: Vairāku īrētāju vidē katra īrētāja Docker Compose failu pārvaldīšana var kļūt nepārvaldāma. Apsveriet augstāka līmeņa orķestrēšanas rīka, piemēram, Kubernetes, izmantošanu, taču tas rada savas drošības apsvērumus.

Secinājums

Konteineru aizbēgšana ir reāls drauds vairāku īrētāju Docker mitināšanā, taču to var novērst. Izprotot izolācijas mehānismus un piemērojot aizsardzību slāņos — nometot iespējas, darbojoties kā ne-root, iespējojot lietotāju vārdu telpas, seccomp, AppArmor, tīkla segmentāciju un regulāru attēlu skenēšanu — jūs varat ievērojami samazināt risku. Atcerieties, ka Docker noklusējuma iestatījumi nav gatavi ražošanai vairāku īrētāju darba slodzēm. Ieviesiet šos soļus jau šodien, lai aizsargātu savus īrētājus un savu infrastruktūru. Lai iegūtu visaptverošu Docker drošības paraugprakses pārskatu, skatiet Jūsu tīmekļa lietojumprogrammu nodrošināšana ar Docker: Praktiskā rokasgrāmata par izolāciju un paraugpraksi.