Valódi több-bérlős elkülönítés elérése Dockerben

Összegzés

A Docker konténerek megosztják a gazda kerneljét, ami biztonsági kockázatot jelenthet a több-bérlős környezetekben, ahol a bérlők nem bíznak egymásban. Ez a cikk elmagyarázza az elkülönítési hiányosságokat az alapértelmezett Docker beállításokban, és konkrét lépéseket nyújt az elkülönítés erősítéséhez Linux névterek, cgroups, felhasználói névterek, seccomp, AppArmor és hardver virtualizáció segítségével. Megtanulod, hogyan konfigurálhatsz bérlőnkénti Docker démonokat, hogyan használhatsz homokozó eszközöket, mint a gVisor vagy a Firecracker az erősebb elkülönítéshez, és hogyan orchestralhatsz Kubernetes segítségével a több-bérlős környezetben. Foglalkozunk a megfelelő infrastruktúra-szolgáltató kiválasztásával is, amely KVM-alapú virtualizációt kínál egy extra elkülönítési rétegért. A végére egy tervet kapsz a biztonságos több-bérlős munkaterhelések futtatásához Dockerrel.

Amikor több bérlőt futtatsz egyetlen Docker gazdagépen, az alapértelmezett konténer elkülönítés – amely Linux névtereken és cgroups-on alapul – gyakran nem elegendő. Egy konténerszökés az egyik bérlőből veszélyeztetheti az egész gazdagépet és az összes többi konténert. Ez a probléma különösen éles a megosztott tárhelyen, SaaS platformokon, vagy bármilyen olyan forgatókönyvben, ahol nem megbízható kód fut a sajátod mellett. A jó hír: több elkülönítési technikát is egymásra rétegezhetsz, hogy megerősített több-bérlős környezetet építs. Ez az útmutató hat gyakorlati lépésen vezet végig, a könnyen elérhetőektől, mint a felhasználói névterek, a fejlett intézkedésekig, mint a homokozó futási környezetek és az infrastruktúra döntések.

A Docker alapértelmezett elkülönítésének megértése

A Docker Linux névtereket használ a folyamatok, hálózat, fájlrendszer és egyéb erőforrások elkülönítésére. A cgroups korlátozza a CPU-t, memóriát és I/O-t. De ezek egyetlen kernelt osztanak meg – a kernelben lévő sebezhetőség az összes konténert érintheti. A valódi több-bérlős környezethez, különösen nem megbízható bérlők esetén, réteges védelemre van szükség. Ahogyan azt a Több-bérlős Docker architektúra tervezése: A megfelelő elkülönítési szint kiválasztása című cikkben tárgyaltuk, az elkülönítési szintek a gyengétől (csak névtér) az erősig (hardver virtualizált) terjednek. Építsünk a leggyengébbtől felfelé.

1. lépés: Felhasználói névterek engedélyezése

Alapértelmezés szerint a konténerben lévő root a gazdán lévő root-ra képeződik le. Egy konténerszökés teljes hozzáférést biztosít a gazdagéphez. A felhasználói névterek átképezik a konténer root-ját egy nem root felhasználóra a gazdán kívül. Engedélyezd globálisan a dockerd --userns-remap=default parancs segítségével, vagy konténerenként a --userns=host kapcsolóval. Ez az egyszerű lépés sok jogosultsági eszkalációs támadást megszüntet. Teszteld az alkalmazásaidat: néhány, amely gazdaszintű jogosultságokat igényel (pl. fájlrendszerek mountolása), elromolhat. Drupal vagy WordPress oldalak esetén általában biztonságos.

2. lépés: Seccomp és AppArmor profilok alkalmazása

A seccomp korlátozza, hogy a konténer milyen rendszerhívásokat hajthat végre. A Docker alapértelmezett seccomp profillal érkezik, amely blokkolja a veszélyes syscall-okat, mint a mount és a reboot. Több-bérlős környezetben szorosabbra veheted – blokkold a ritka syscall-okat, amelyeket a szökési eszközök használnak. Hasonlóképpen, az AppArmor korlátozhatja a konténer folyamatait. Hozz létre egy egyéni AppArmor profilt, amely megtagadja az írási hozzáférést a kernel interfészeihez és korlátozza a fájlútvonalakat. Mindkettő a --security-opt kapcsolókkal állítható be. Kombináld őket réteges védelem érdekében.

3. lépés: Bérlőnkénti Docker démonok használata

Egyetlen Docker démon futtatása az összes bérlő számára kockázatos – bármely konténerszökés hozzáférhet a démon socket-hez. Izoláld a démonokat bérlőnként a Docker-in-Docker (DinD) vagy távoli démon végpontok segítségével. Például indíts el egy Docker démont egy konténerben a --privileged kapcsolóval (de ez gyengíti az elkülönítést). Jobb megközelítés: futtass külön démonokat külön VM-eken, vagy használd a Docker kísérleti --group funkcióját felhasználói névterekkel. Orchestráció esetén a Kubernetes névtér-alapú elkülönítés praktikusabb, ahogy azt a Container Escape elleni védekezés: Gyakorlati útmutató a Docker elkülönítéshez több-bérlős tárhelyhez című cikk tárgyalja.

4. lépés: Homokozó futási környezetek megfontolása

Amikor a Linux kernel maga nem megbízható, használj egy homokozó futási környezetet, amely egy könnyű VM réteget ad hozzá. A gVisor (runsc) elfogja a syscall-okat és saját kernelt implementál, míg a Firecracker mikro-VM-eket használ hardver virtualizációval. Mindkettő integrálható a Dockerrel a containerd futási környezeteken keresztül. Például add hozzá a "runtimes": {"runsc": {}} sort a Docker démon konfigurációjához, és futtasd a konténereket a --runtime=runsc kapcsolóval. A teljesítmény többlet 5–15%, de az elkülönítés lényegesen erősebb. Ideális a magas biztonságú több-bérlős beállításokhoz.

5. lépés: Orchestráció Kubernetes és biztonsági szabályzatok segítségével

A Kubernetes natív több-bérlős képességeket biztosít névterek, Pod Biztonsági Szabványok és NetworkPolicy-k révén. Definiálj bérlőnkénti névtereket erőforráskvótákkal, és alkalmazd a korlátozott pod biztonsági kontextusokat (minden képesség eldobása, csak olvasható root fájlrendszer). Beléptető vezérlők, mint az OPA/Gatekeeper, megakadályozhatják a helytelen konfigurációkat. Ha sok bérlőt kezelsz, a Kubernetes automatizálja az elkülönítés kényszerítését. A produkciós szintű orchestrationhoz lásd a Túl a Docker Compose-on: Production-Ready konténeres alkalmazások orchestrálása című cikket.

6. lépés: A megfelelő tárhelyszolgáltató kiválasztása

Az infrastruktúra-szolgáltató hypervisora számít. A Docker megosztott tárhelyen (OpenVZ) gyenge elkülönítést ad – egy bérlő láthat más folyamatokat. Részesítsd előnyben a KVM-et vagy VMware-t használó szolgáltatókat, amelyek hardverszintű elkülönítést biztosítanak. Az olyan szolgáltatók, mint a DigitalOcean, Kamatera vagy AWS, KVM-alapú VPS-t kínálnak dedikált erőforrásokkal. Bare-metal esetén győződj meg róla, hogy a BIOS-szintű virtualizáció engedélyezve van a beágyazott konténerekhez. Egy szolgáltató, amely a bérlőket hypervisor szinten elkülöníti, kiegészíti a konténer elkülönítését. Ahogy azt a A Docker elkülönítés elsajátítása a biztonságos és hatékony webes tárhelyhez című cikk részletezi, a gazda operációs rendszert is meg kell erősíteni minimális támadási felülettel.

Óvintézkedések és kompromisszumok

Minden további réteg növeli a komplexitást és a teljesítményköltséget. A felhasználói névterek eltörhetik a gazdára mountolt köteteket. A seccomp profilok hangolást igényelnek alkalmazásonként. A homokozó futási környezetek, mint a gVisor, nem támogatják az összes syscall-t – az alkalmazásod esetleg nem működik. A bérlőnkénti Docker démonok növelik a memória többletet. Válaszd ki a fenyegetési modellnek megfelelő elkülönítési szintet: megbízható bérlők esetén az alapértelmezett névterek elegendőek lehetnek; nyilvános SaaS esetén fektess be futási környezet homokozókba és Kubernetes szabályzatokba. Tesztelj alaposan élesítés előtt.

Következtetés

A valódi több-bérlős elkülönítés Dockerben elérhető több kernel funkció, futási környezet homokozó és orchestációs vezérlők rétegezésével. Kezdd a felhasználói névterekkel és seccomp-pal, majd lépj tovább a bérlőnkénti démonokra vagy homokozó futási környezetekre. Nagyméretű telepítésekhez a Kubernetes szabályzatalapú elkülönítést biztosít. Mindig párosítsd egy hypervisor szinten elkülönített gazdagéppel egy megbízható szolgáltatótól. Egyetlen technika sem golyóálló, de kombiniálásuk robusztus védelmet hoz létre. A bérlőid hálásak lesznek – és a biztonsági auditod is.