Sigurnost kontejnera: Je li izolacija apsolutna? (Docker vs. Rootless Podman)

5

0

čitati 11 min.

Temeljna ograničenja izolacije kontejnera

Kontejnerizacija je postala dominantna metoda za pakiranje i isporuku aplikacija u cloud i mikroservisnim arhitekturama. Kontejneri omogućuju pakiranje koda, biblioteka i ovisnosti, osiguravajući visoku prenosivost i operativnu učinkovitost.

Međutim, masovna migracija kritičnih opterećenja na kontejnere čini otpornost mehanizama izolacije temeljnom brigom. Istraživanja i ankete DevOps i sigurnosnih timova dosljedno pokazuju da sigurnost kontejnera ostaje jedna od glavnih briga: ranjivosti kernela i runtime okruženja, uz konfiguracijske greške, redovito dovode do stvarnih povreda izolacije.

Ključno pitanje je: Je li izolacija kontejnera apsolutna?

Odgovor je ne, a razlog leži u njihovoj arhitekturi. U ovom članku dublje ćemo proučiti ovo pitanje i istražiti mjere dostupne za ublažavanje rizika od ranjivosti.

Kontejneri protiv virtualnih strojeva: dijeljeni kernel

Virtualni stroj (VM):

• Svaki VM pokreće vlastiti OS kernel, potpuno odvojen od hosta.

• Izolaciju provodi hipervizor (KVM, Xen, ESXi, itd.).

• Napad obično mora ciljati hipervizor, što značajno sužava vektore napada.

Kontejneri:

• Kontejner je proces izoliran korištenjem primitiva Linux kernela (namespaces, cgroups, itd.).

• Kontejner sadrži samo korisnički prostor (biblioteke, runtime, aplikaciju) ali dijeli jedan kernel s hostom i drugim kontejnerima.

• Bilo koja kritična ranjivost kernela automatski postaje potencijalni vektor napada za sve kontejnere na čvoru.

Arhitektonski izbor dijeljenog kernela je ono što čini izolaciju kontejnera fundamentalno neapsolutnom: uspješna eksploatacija ranjivosti kernela omogućuje napadaču zaobilaženje granica bilo kojeg namespace-a.

Uloga namespace-a i Cgroups-a u stvaranju izolacije

Temelj izolacije kontejnera u Linuxu počiva na Namespace-ima i Cgroups-ima.

• Namespaces – Izolacija prikaza sustava: PID, Mount, Network, User, IPC, UTS i drugi. Procesi "vide" samo svoj vlastiti prostor: svoj datotečni sustav, svoje PID-ove, svoje ime hosta i svoju mrežu.

• Cgroups – Kontrola i ograničavanje resursa: CPU, memorija, I/O, broj procesa, itd.

Namespace-i stvaraju iluziju odvojenog sustava, a Cgroups sprječavaju jedan kontejner da monopolizira resurse hosta. Međutim, ključno je napomenuti da Namespace-i su mehanizam izolacije, a ne puni sigurnosni mehanizam protiv namjernog zaobilaženja barijera. Ne sprječavaju eksploataciju ranjivosti kernela, ne rješavaju probleme s pretjeranim root privilegijama ili privilegiranim kontejnerima, ne filtriraju sistemske pozive i ne upravljaju politikama pristupa.

Stoga su namespace-i i Cgroups-i samo osnovni sloj koji mora biti ojačan sa:

1. Filtriranjem sistemskih poziva (Seccomp)

2. MAC politikama (AppArmor/SELinux)

3. Ograničenjima Capability-a

4. Idealno, User Namespaces + rootless način rada

Sigurnost platforme kontejnera: kritične prijetnje i vektori napada

Površina napada platforme kontejnera je višeslojna. Mogu se identificirati sljedeće glavne površine:

• Runtime i kernel (runc, containerd, CRI-O, Linux kernel).

• Lanac opskrbe slika.

• Konfiguracija kontejnera i orkestatora.

• Cloud i infrastruktura (IAM, API, pohrana, mreža).

Pregled vektora napada i kritičnih ranjivosti: Container Escape

Tipični vektori u okruženju kontejnera uključuju: eksploataciju CVE-a u Linux kernelu ili container runtime-u; korištenje nesigurnih slika (zastarjeli paketi, exploit kitovi); konfiguracijske greške u Kubernetescu/Dockeru (prekomjerne privilegije, montiranje datotečnog sustava hosta, mrežni stack hosta); i kompromitaciju registra i CI/CD-a.

Važno je razumjeti da je Container Escape često kombinacija faktora:

Ranjivost kernela/Runtime-a + Loša konfiguracija (pokretanje kao root, --privileged, montiranje datotečnog sustava hosta, nedostajući MAC/Seccomp).

Ranjivosti lanca opskrbe

Lanac opskrbe slika kontejnera jedan je od glavnih rizika jer osnovne slike iz javnih registra često sadrže poznate CVE-ove. Ovisnosti (pip/npm/gem/go moduli) se povlače tranzitivno i nisu uvijek kontrolirane. Najopasniji je zlonamjerni softver koji može biti "uspavan" i samo se manifestirati pri izvođenju.

Stoga su sljedeće najbolje prakse obvezne u produkciji:

• Skeniranje slika za CVE-ove, korištenjem alata poput Trivy, Clair, Grype, itd.

• Korištenje registra svjesnih politika s provođenjem, kao što su Harbor, Quay ili GHCR.

• Potpisivanje i provjera slika prije implementacije.

Konfiguracijske greške i privilegirani kontejneri

Najčešća greška koja širom otvara vrata ranjivostima je pokretanje procesa unutar kontejnera kao root! Ako je aplikacija u kontejneru pokrenuta s pravima superkorisnika, pri kompromitaciji kontejnera napadač dobiva root unutar kontejnera. Uspješan bijeg izvan kontejnera tada značajno pojednostavljuje eskalaciju do root hosta.

Zabranjivanje pokretanja aplikacija kao root i korištenje neprivilegiranog UID/GID-a osnovno je pravilo ispravnog učvršćivanja.

Privilegirani kontejneri koji koriste zastavicu --privileged praktično onemogućuju ključne mehanizme izolacije, točnije neke Cgroups, AppArmor/SELinux i Seccomp ograničenja. To daje kontejneru izravan pristup uređajima hosta i pseudo-datotečnim sustavima (/proc, /sys, /dev, itd.). Iz privilegiranog kontejnera lako je montirati diskove hosta i modificirati datotečni sustav i konfiguracije.

U suštini, privilegirani kontejner je ekvivalent namjerne eskalacije privilegija. Zapamtite, ovo je prihvatljivo samo u rijetkim, dobro izoliranim scenarijima, a svakako ne u višeklijentskom okruženju.

Postoje i "tihe" konfiguracijske greške koje mogu učiniti okruženje kontejnera ekstremno ranjivim, čak i bez korištenja zastavice --privileged. Najopasniji su:

• Montiranje hostPath na osjetljive direktorije hosta, kao što su /etc ili /var/run/docker.sock.

• Davanje nepotrebnih Capability-ja, na primjer, CAP_SYS_ADMIN, koji praktično daje root prava na hostu.

• Neopravdano korištenje hostNetwork ili hostPID načina rada.

Ove naizgled sitne postavke mogu omogućiti napadaču da pobjegne iz kontejnera i preuzme kontrolu nad kernelom ili cijelim host sustavom.

Usporedba arhitekture: Docker protiv Podmana

Arhitektonske razlike između Dockera i Podmana izravno utječu na model prijetnji. Docker, sa svojim daemon-om visokih privilegija, predstavlja glavni rizik: jednu točku kvara.

Docker i rootful način rada

U klasičnoj, ili standardnoj, Docker arhitekturi, Docker CLI komunicira s dockerd daemon-om putem /var/run/docker.sock socketa ili TCP-a. Dockerd daemon radi kao root korisnik i izvršava osnovne operacije:

• Stvaranje/brisanje kontejnera

• Izgradnja slika

• Upravljanje mrežama/volumenima

• Interakcija s registrima

Slijedi da je izravan pristup Docker API-ju ekvivalentan gotovo potpunom root pristupu hostu – omogućavajući napadaču montiranje datotečnog sustava, pokretanje privilegiranih kontejnera, itd. U ovom scenariju, daemon postaje jedna točka kvara – ako je kompromitiran, napadač dobiva pristup hostu.

Stoga Docker zahtijeva strogu kontrolu pristupa socketu, obvezno omogućavanje MAC-a i Seccompa, te ograničavanje Capability-ja. Ključno je minimizirati broj korisnika i usluga s pristupom Docker API-ju.

Daemon-less Podman: izvorni linux pristup

Podman je razvijen od strane Red Hata i zajednice kao sigurnija, "izvorna" Linux alternativa. Originalno je dizajniran s daemon-less arhitekturom, što znači da nema trajnog, centraliziranog daemon-a. Umjesto toga, kontejneri su podređeni procesi korisnika koji je pokrenuo naredbu. Temelj je duboka integracija sa systemd-om, gdje se jedinice i usluge stvaraju izravno.

Time se eliminira jedinstvena točka kvara koju predstavlja root daemon i bolje se usklađuje s tradicionalnim Unix modelom: "tko pokrene proces, vlasnik je".

Rootless način rada: User Namespaces kao glavna sigurnosna barijera

Rootless način rada je u suštini logični odgovor na temeljnu opasnost: "Što ako kontejner ipak izađe?"

Uloga user namespace-a i ublažavanje štete

User Namespaces izoliraju UID/GID i omogućuju UID remapiranje. Na primjer, ako proces unutar kontejnera ima UID 0 (root), taj isti proces je mapiran na neprivilegirani UID iz subuid/subgid raspona na hostu.

Stoga, čak i ako napadač unutar kontejnera ima root privilegije i uspije iskoristiti ranjivost runtime-a/kernela kako bi pobjegao na razinu hosta, nastavlja djelovati kao neprivilegirani korisnik na hostu.

Mnogi lanci eksploatacije, uključujući runc-escape, su time razbijeni ili imaju značajno smanjen utjecaj. To je zato što napadač ne može prebrisati binarne datoteke/konfiguracije u vlasništvu roota, ne može montirati datotečne sustave ili upravljati uređajima bez Capability-ja, a MAC politike nastavljaju djelovati i na hostu.

Rootless Podman: Ograničenja i mrežni stack

Podman je od početka dizajniran s fokusom na rootless operacije. Kontejnere stvara i upravlja neprivilegirani korisnik, user namespace-i su omogućeni po zadanim postavkama, a SELinux/AppArmor i Cgroups se koriste u mjeri u kojoj je to moguće bez root pristupa.

Međutim, postoje neki kompromisi u ovoj shemi. Kada rootless kontejner djeluje unutar subuid/subgid raspona, moguće su greške mapiranja ako slika sadrži datoteke s UID/GID vrijednostima koje padaju izvan ovog raspona.

Drugi neizravni nedostatak je što neprivilegirani korisnik ne može slobodno konfigurirati network namespace-e. Od početka 2025., Podman koristi user-space stack pasta kao zamjenu za slirp4netns. Ovaj plugin djeluje potpuno u korisničkom prostoru, ali zahvaljujući tap sučelju i zero-copy splice mehanizmu, isporučuje gotovo izvornu mrežnu performansu. Ipak, usporavanja performansi su još uvijek moguća, i definitivno su zajamčena ako korisnici nastave koristiti slirp4netns.

Rootless Docker: implementacija i zahtjevi

Docker također podržava potpuni rootless način rada, u kojem se dockerd daemon i kontejneri pokreću unutar user namespace-a bez privilegija root korisnika hosta. Važno je, ovo se razlikuje od starijeg userns-remap svojstva, gdje je sam daemon ostao privilegiran.

Sa sigurnosnog stajališta, ovo jamči da povreda kontejnera neće rezultirati automatskom eskalacijom na razinu root korisnika hosta. U slučaju uspješnog napada na dockerd u rootless načinu rada, pristupat će se samo resursima neprivilegiranog korisnika, a ne cijelom sustavu.

Izbor između rootful i rootless načina rada prvenstveno je ravnoteža između maksimiziranja performansi i maksimalnog ograničavanja potencijalne štete u slučaju povrede.

Zaključci i preporuke za učvršćivanje

Analiza potvrđuje da izolacija kontejnera nije apsolutna zbog njihove arhitekture. Budući da kontejneri dijele kernel host sustava, ranjivosti na razini kernela ili runtime-a mogu, po definiciji, "vidjeti" preko namespace-a, krše očekivane sigurnosne granice.

U praksi, većina uspješnih napada povezana je s kombinacijom poznate ranjivosti (kernel/runc) i slabe konfiguracije (root, --privileged, hostPath).

Pouzdan model sigurnosti kontejnera mora biti izgrađen kao višeslojni sustav:

Sloj 1 – Segmentacija: (namespace-i, cgroups)

Sloj 2 – Politike i filtriranje: (Seccomp, MAC, Capabilities)

Sloj 3 – Arhitektonsko ograničavanje privilegija: (putem rootless načina rada i User Namespace-a)

Kontrolna lista: učvršćivanje hosta za Docker i Podman kontejnere

Rootless po zadanim postavkama

Razmotrite Podman ili Docker u rootless načinu rada kao zadani model za interna i višeklijentska opterećenja.

Učvršćivanje kernela i zakrpljivanje

Promptno ažurirajte kernel (Dirty COW, Dirty Pipe i slični CVE-ovi su gotovo uvijek već riješeni zakrpama). Koristite distribucije s dobrom poviješću sigurnosnih zakrpa (RHEL, OpenSUSE, Ubuntu LTS, itd.).

Usvajanje specijaliziranih nepromjenjivih OS distribucija

Za poboljšanje sigurnosti okruženja kontejnera, koristite nepromjenjive OS distribucije kao što su openSUSE MicroOS ili Flatcar Linux. Njihov korijenski datotečni sustav je po zadanim postavkama samo za čitanje, što značajno smanjuje površinu napada. Ključni mehanizam su atomska ažuriranja: stvara se nova OS slika, a ažuriranje se ili primjenjuje potpuno ili se potpuno vraća, sprječavajući korupciju sustava i ubrzavajući oporavak.

Načelo najmanjih privilegija

Nikada ne koristite zastavicu --privileged u produkciji, osim za visoko specijalizirana, izolirana okruženja. Izbjegavajte pokretanje aplikacija unutar kontejnera kao root korisnik i koristite datotečni sustav samo za čitanje, minimalni skup Capability-ja i stroge Seccomp profile.

MAC politike i Seccomp

Omogućite i konfigurirajte SELinux\AppArmor za kontejnere. Koristite Seccomp profile, idealno prilagođene na temelju stvarnih sistemskih poziva aplikacije, a ne samo Docker zadanih postavki.

Sigurnost lanca opskrbe

Implementirajte skeniranje slika kontejnera. Ograničite izvore osnovnih slika na službene ili interne registre i omogućite potpisivanje i provjeru slika prije implementacije.

Praćenje tijekom izvođenja

Koristite alate za detekciju anomalija i kontejner IDS/EDR (Falco, Sysdig Secure ili Aqua Security) koji mogu detektirati pokušaje bijega iz kontejnera i pratiti izvršavanje zlonamjernih naredbi. Pratite atipični mrežni promet, neočekivane sistemske pozive i pristup osjetljivim datotekama.

Budućnost izolacije: Kata Containers, gVisor i Micro-VM-ovi

Rootless način rada značajno smanjuje rizik potpune kompromitacije hosta, ali ne rješava sve, jer ovisnosti o host kernelu ostaju i neke klase napada nisu eliminirane.

Stoga hibridni pristupi dobivaju na popularnosti za kritična opterećenja:

• Kata Containers: Svaki pod ili kontejner se pokreće unutar laganog mikro-VM-a s zasebnim kernelom, kombinirajući prednosti VM-ova i kontejnera.

• gVisor: Sandbox kernel napisan u Go koji djeluje kao posrednički sloj između aplikacije i pravog Linux kernela.

Ova rješenja smanjuju oslanjanje na dijeljeni kernel i približavaju nas modelu izolacije VM-a zadržavajući deklarativnu prirodu i praktičnost orkestatora kontejnera.

Pretvorite smjernice iz ovog posta u stvarnu sigurnost na vašoj sljedećoj implementaciji.

Nabavite VPS ili Dedicated Server i počnite postavljati sigurnu platformu kontejnera danas.

Nastavite na odabir konfiguracije.

Novi članci:

Docker vs. Podman: Potpuni vodič za Daemon-less kontejnerizaciju.