Docker můžete provozovat měsíce bez viditelných problémů. Kontejnery se spustí, aplikace reagují, nic se nerozbije. Pak jeden otevřený port nebo jedna chybná konfigurace práv vytvoří vstupní bod, který útočník nemusel si vydělat. Chyby v Docker bezpečnosti většinou nevypadají jako chyby, dokud se něco nepokazí.
Tento článek popisuje konkrétní konfigurace, které ohrožují prostředí kontejnerů, co každá z nich útočníkům umožňuje, a končí checklistem, který si můžete spustit proti vlastnímu nastavení ještě dnes.
Proč je Docker bezpečnost složitější, než se zdá
Kontejnery se cítí izolované. Spustíte jeden, běží si svůj prostor procesů, a zevnitř příští kontejner neexistuje. Izolaci máte, ale je jen částečná. Kontejnery sdílí kernel hostitele, což znamená, že proces uvnitř kontejneru se za určitých podmínek dostane až na hostitelský systém.
Docker se standardně konfiguruje pro pohodlí vývojářů, ne pro bezpečnost v produkci. Root přístup je zapnutý. Všechny porty lze vázat na všechna rozhraní. Žádné monitorování běhu. Většina vývojářů tato nastavení akceptuje, nasadí kontejner a jde dál. Tento přístup je rozumný pro začátek, ale není to hotová bezpečnostní pozice.
Podle Zpráva Red Hat 2024 State of Kubernetes Security, 67 % organizací zpomalilo nebo odložilo nasazení aplikací kvůli bezpečnostním obavám z kontejnerů nebo Kubernetes. Toto třením obvykle nejsou útoky. Pochází z toho, že týmy zjistily, že jejich nastavení kontejnerů potřebuje zesílení bezpečnosti, které nevytvořily.
Často vidíme kontejnery běžící v produkci se stejnou konfigurací, jakou měly na počítači vývojáře. To je místo, kde se chyby v Docker bezpečnosti tiše hromadí bez viditelných příznaků, dokud se něco neaudituje nebo neselže.
Chyby, které tyto mezery vytváří, jsou konkrétní, předvídatelné a většinou se jim lze vyhnout, počínaje úrovní konfigurace.
Běžné chyby v konfiguraci Docker
Většina průniků do kontejnerů nezačíná zero-day exploitem. Začíná konfigurací nastavenou na prvním dni, bez większího uvažování o síťové exposici nebo rozsahu oprávnění.
Výchozí nastavení Docker fungují. Propast mezi funkčností a bezpečností je místo, kde se bezpečnostní rizika Docker kontejnerů hromadí, zvlášť v samostatně hostovaných nastaveních, která se nasadí a už se k nim nevrátí.
Vidíme tento vzor často: kontejnery na serverech s veřejnou IP, vázané porty, uživatelská nastavení a síťové konfigurace přesně takové, jaké byly při prvním nasazení.
Spuštění kontejnerů s oprávněním root
Když spustíte kontejner Docker bez zadání uživatele, běží jako root. To znamená, že jakýkoli proces v kontejneru, včetně vaší aplikace, má práva na úrovni roota v namespace kontejneru.
Root v kontejneru není totéž co root na hostiteli, ale oddělení není absolutní. Exploity eskalace oprávnění zaměřené na runtime, jako jsou dobře zdokumentované CVE-2019-5736 v runc a podobné chyby runtime, často vyžadují, aby proces v kontejneru běžel s právy roota.
Kontejnery bez roota eliminují požadavek na rootovský proces, na kterém tyto exploity závisí, a výrazně zužují útočnou plochu pro tuto třídu zranitelností, ačkoli zcela neodstraňují riziko úniku z kontejneru.
Přidání direktivy USER do vašeho Dockerfile to řeší. Některé oficiální image jsou dodávány s neprivilegovaným uživatelem, kterého můžete aktivovat pomocí direktivy USER, ale mnohé stále defaultují na roota bez připraveného uživatele pro aplikaci. V těchto případech uživatele vytvoříte v Dockerfile před přepnutím na něj. U většiny samoobslužných nastavení tato jediná změna eliminuje celou kategorii rizika eskalace.
Vystavení příliš mnoha portů na veřejný internet
Když publikujete port pomocí Docker, Docker zapisuje své vlastní iptables pravidla přímo. Tato pravidla se spouští před pravidly firewallu na úrovni hostitele. Toto je chování dobře známé z hlášení komunity a zdokumentované v průvodci filtrováním paketů Docker, nikoli chybná konfigurace, a znamená to, že UFW a podobné nástroje neblokují to, co již Docker otevřel.
Docker zapisuje přímo do iptables, obcházející výchozí nastavení UFW a firewalld na mnoha hostitelích Linux. To znamená, že port vázaný na 0.0.0.0 může být veřejně dosažitelný, i když se zdá, že je váš firewall nakonfigurován. Cloud bezpečnostní skupiny a DOCKER-USER chain pravidla mohou provoz stále blokovat, takže skutečné vystavení závisí na vašem konkrétním nastavení sítě.
Vážte služby na 127.0.0.1 kde je to možné, směřujte veřejně přístupný provoz přes reverzní proxy a publikujte pouze to, co skutečně vyžaduje externí přístup. Reverzní proxy je nejspolehlivější způsob, jak kontrolovat, co je vystaveno zvenčí hostitele.
Zanedbávání síťové izolace mezi kontejnery
Jakýkoli kontejner v této síti může dosáhnout jakéhokoli jiného kontejneru bez omezení. Výchozí bridge neuplatňuje žádné filtrování provozu mezi kontejnery, které ji sdílejí, a většina nastavení tuto konfiguraci nikdy nezmění.
Pokud se jeden kontejner kompromituje, tato otevřená komunikace se stane cestou pro laterální pohyb. Frontend kontejner může dosáhnout databáze, interního API nebo čehokoliv jiného ve stejné výchozí bridge síti, i když tento přístup nikdy nebyl zamýšlen.
Uživatelsky definované sítě vám dávají explicitní kontrolu nad tím, které kontejnery si mohou komunikovat, ale jediná vlastní síť sdílená všemi vašimi službami stále umožňuje volný mezicontejnerový provoz. Skutečná izolace vyžaduje umístění služeb, které spolu nesmí komunikovat, na oddělené sítě. Vypnutí výchozího bridge je začátek, nikoli cíl.
Přehlédnutí socketu Docker
Socket Docker na /var/run/docker.sock je řídicí rozhraní celého enginu Docker. Připojení do kontejneru mu dává přímý přístup API k daemonu běžícímu na hostiteli.
S tímto přístupem může kontejner spustit nové kontejnery, připojit adresáře hostitele, kontrolovat a upravovat běžící kontejnery a efektivně kontrolovat hostitelský stroj. Útočná plocha je ekvivalentní rootu na hostiteli, což je důvod, proč kterýkoli nástroj, který vyžaduje přístup k socketu, zaslouží pečlivé vyhodnocení.
Pro většinu případů existují bezpečnější alternativy: omezeným rozsahem API nebo nástroje pro správu Docker , které nevyžadují přístup k socketu. Docker-in-Docker má své vlastní bezpečnostní a operační kompromisy a není přímou náhradou.
Chyby v konfiguraci vytvoří počáteční riziko. Volba image a závislostí určuje, jak se toto riziko v čase kumuluje.
Chyby v image a správě tajemství, která přežijí kontejner
Když zastavíte kontejner, chyby v jeho konfiguraci se zastaví s ním. Když znovu vytvoříte image, která nese zranitelnost nebo pevně zakódované přihlašovací údaje, problém se restartuje s kontejnerem. Chyby na úrovni image se mezi nasazeními neresetují.
Cestují s image do každého prostředí, které ji stáhne, každého registru, který ji uloží, a každého člena týmu, který ji spustí. Tato perzistence dělá ze správy image a tajemství zvláštní kategorii rizika, která stojí za samostatné auditování od konfigurace.
Vidíme tento vzor často: image vybraná pečlivě na začátku projektu a od té doby nikdy znovu nevytvořená, která se pomalu vzdaluje od bezpečnostní úrovně, kterou původně představovala.
Používání nedůvěryhodných nebo zastaralých image
Veřejné registry jsou otevřené všem. Nebezpečné image byly distribuovány přes Docker Hub s těžaři kryptoměn a backdory vloženými v historii vrstev, které přežijí restartování kontejneru. Ověření před stažením je důležité, zejména u image od neoficiálních nebo neznámých vydavatelů.
Oddělený problém je zastaralost. Oficiální image, kterou jste stáhli před šesti měsíci a od té doby nikdy znovu nevytvořili, hromadí neopravené Docker zranitelnosti s každou zveřejněným CVE proti jejím balíčkům. Image není rozbitá. Prostě již není aktuální.
Zpráva Sonatype State of the Software Supply Chain 2024 zjistila, že 95% času, kdy je spotřebována zranitelná komponenta, je opravená verze již dostupná, a 80% závislostí aplikací zůstává bez upgradu déle než rok. Tento vzor platí také pro Docker základní image, protože se opírají o stejné open-source balíčky.
Používejte oficiální image z ověřených vydavatelů a definujte konkrétní tagy verzí místo spoléhání se na "latest". Vytvořte pravidelný plán opětovného vytvoření, abyste udrželi vaše image aktuální.
Pevné zakódování tajemství v Dockerfiles a Compose souborech
Přihlašovací údaje zapsané do Dockerfile instrukce ENV nebo ARG, pevně zakódované v bloku Compose environment, předané jako argumenty buildu nebo uložené v souboru .env potvrzeném do správy verzí nezmizí, když zastavíte kontejner. Zůstávají v historii vrstev image nebo správě verzí, přístupné každému, kdo se může dostat k oběma.
Toto je jedna z nejčastěji přehlížených Docker bezpečnostních chyb, protože během vývoje nezpůsobuje viditelné problémy. API klíč v instrukci ENV funguje správně. Je také v repozitáři, zapečený v image a distribuován všude, kam image putuje.
Moderní Docker Compose podporuje nativní mechanismus tajemství, který připojuje přihlašovací údaje za běhu bez jejich zapečení do image. Docker tajemství API a externí správci tajemství sledují stejný princip. Jedná se o možnosti, které udržují přihlašovací údaje zcela mimo build artefakty a potvrzené soubory.
Proměnné prostředí za běhu jsou zlepšením oproti pevně zakódovaným přihlašovacím údajům, ale stále jsou vystaveny prostřednictvím výstupu Docker inspect, logů a výpisy chyb. Jsou to krok dopředu od zapečených tajemství, ne hotové řešení.
Pravidelnému aktualizování image kontejneru
Spouštění stejné image po měsíce je běžná zvyklost. Každý den, který projde poté, co je zveřejněna nová zranitelnost, ale před tím, než ji znovu vytvoříte, vaše kontejnery nášují exponenciálně rostoucí okno rizika bez jakékoliv viditelné změny.
Vytvořte konzistentní plán opětovného vytvoření. Automatizujte tento proces, kde je to možné, a pravidelně spouštějte skener zranitelností proti vašim aktuálním image. Cílem není dokonalost. Jde o zúžení času mezi vydáním záplaty a jejím nasazením.
Kontrola přístupu a monitorování se mohou zanedbat při rychlém nasazování. Jsou také kategorie, kde incidenty zůstávají dlouho nezjištěny.
Mezery v řízení přístupu a viditelnosti
Poté, co je kontejner spuštěn se solidní konfigurací a aktuálními image, zůstávají dvě kategorie selhání. Oba jsou ze své podstaty neviditelné: nenotujete problém se slabou kontrolou přístupu, dokud jej někdo nepoužije, a nenotujete mezeru v monitorování, dokud jej nepotřebujete k vyšetřování aktivity, která nikdy nebyla zaznamenána.
Stejné Red Hat 2024 výzkum zjistilo, že 42 % týmů postrádalo dostatečné možnosti k řešení zabezpečení kontejnerů a souvisejících hrozeb.
Zjišťujeme, že mezery v monitorování se typicky objevují během vyšetřování incidentů, ne předtím. Když se viditelnost stane prioritou, obvykle se už řeší něco, co se stalo, místo aby se to předcházelo.
Slabé ověřování a odhalené řídicí panely
Řídicí panel kontejnerů na veřejné IP adrese bez ověřování nevyžaduje sofistikovaného útočníka. Stačí, aby věděl, kde se nachází. To je nižší bariéra, než si většina týmů uvědomuje.
Samoobslužné nástroje pro monitorování a správu se obvykle nasazují s webovým rozhraním přístupným na všech síťových rozhraních. Jejich umístění na veřejnou IP adresu bez ověřování je kontejnerový ekvivalent otevřeného administračního panelu.
Ověřování, reverzní proxy a umístění v privátní síti jsou základ. Řízení přístupu je konfigurační krok, který přidáte do jakéhokoli administračního rozhraní, ne něco, co se dodává zapnuté.
Totéž platí pro Docker CLI a GUI správu; přístup na úrovni administrátora k démonu přináší stejné riziko bez ohledu na rozhraní.
Nemonitorování toho, co vaše kontejnery dělají
Pokud je kontejner kompromitován, aktivita útočníka zanechává stopu: změny v chování procesů, neobvyklá síťová připojení a neočekávané úpravy souborů. Bez sběru logů v místě se tato stopa v použitelné podobě neexistuje.
Centralizovaný sběr logů, audit logů kontejnerů a nástroje pro runtime monitoring vám poskytují data k detekci abnormální aktivity dřív, než se situace zhorší. Cíl není analyzovat každý řádek. Je to mít data k dispozici, když potřebujete vyšetřit.
Kontejnerová nastavení, která v produkci běží tiše bez logistického kanálu a bez upozornění, nejsou nízkopříslušová. Jsou neinspektovaná. To jsou dva různé provozní stavy.
Proč také záleží na infrastruktuře prostředí
Bezpečnost kontejnerů začíná konfigurací, ale konfigurace běží na infrastruktuře. Server se špatně nakonfigurovanou sítí, sdílenými prostředky nebo bez filtrování na úrovni sítě vytváří podmínky, které ovlivňují každý kontejner nad ním. Správné nastavení kontejneru a správná konfigurace serveru jsou dva oddělené úkoly.
Mnoho mezer v zabezpečení Docker je zesíleno podmínkami, které kontejnery samy zdědí:
- Server se sdíleným nájmem bez hardwarové izolace mezi nájemci
- Hostitelské jádro bez oprav
- Hostitel bez vestavěného filtrování na úrovni sítě
To neodstraňuje potřebu kroků konfigurace výše, protože správné posílení kontejnerů je důležité bez ohledu na vrstvu infrastruktury. Zahájení izolované infrastruktury odstraňuje jednu vrstvu obav z rovnice.
V Cloudzy nabízíme dvě možnosti podle toho, co vaše nastavení vyžaduje:
- Linux VPS: čisté prostředí pro nasazení Docker a aplikaci kroků pro posílení bezpečnosti z tohoto článku
- Portainer VPS: možnost jedním kliknutím s předinstalovaným Portainer; server se spustí a vy už jste v ovládacím panelu
Obě možnosti běží na stejné infrastruktuře: virtualizace KVM, AMD Ryzen 9 CPUs s boost clockem až 5,7 GHz, DDR5 paměť, NVMe SSD úložiště, až 40 Gbps síť a bezplatná ochrana DDoS přes filtrování BuyVM, na 12 globálních místech s 99,95% SLA dostupnosti.
Podrobněji se na spuštění Portainer na VPS podíváme v samostatném článku.
Praktický bezpečnostní checklist pro nasazení Docker
Výše zmíněné bezpečnostní chyby Docker pochází většinou z jednorázových rozhodnutí o konfiguraci, která se nikdy nezmění. Spuštění tohoto checklistu proti existující konfiguraci odhalí mezery. Funguje jako audit, ne jako průvodce nasazením.
Tyto bezpečnostní doporučení Docker pokrývají, jak chránit kontejnery Docker proti nejčastějším selháním konfigurace popsaným výše.
Rychlá reference: Všechny 4 chyby
| Chyba | Kategorie | Jednořádková oprava |
| Spuštěno jako root | Konfigurace | Přidat USER direktiva do vašeho Dockerfile |
| Porty vázané na 0.0.0.0 | Konfigurace | Připojte se na 127.0.0.1 a směrujte přes reverzní proxy |
| Bez izolace sítě | Konfigurace | Rozdělte služby do samostatných uživatelem definovaných sítí na základě potřeb přístupu. |
| PřiPOJen socket Docker | Konfigurace | Odeberte připojení; používejte omezené APIs nebo alternativy |
| Nedůvěryhodné nebo zastaralé image | Obrázek | Používejte oficiální image s připnutými verzemi tagů |
| Pevně zakódovaná tajemství | Obrázek | Přesuňte přihlašovací údaje do runtime proměnných prostředí nebo správce tajemství |
| Žádný plán opětovného vytvoření image | Obrázek | Nastavte měsíční kadenci opětovného vytváření; automatizujte kde je to možné |
| Neověřené dashboardy | Přístup | Přidejte autentifikaci a přesuňte rozhraní správy do privátních sítí |
| Žádný sběr logů kontejneru | Přístup | Nastavte centralizované logování a monitorování za běhu |
Doporučujeme jej nejprve spustit proti existujícím konfigurací, protože tam jsou mezery s největší pravděpodobností již přítomny.
Kontejnery spuštěné jako ne-root: Zkontrolujte vaše Dockerfiles na direktivu USER. Pokud žádná neexistuje, kontejner běží jako root.
Vazby portů omezené na localhost nebo proxy: Spusťte docker ps a zkontrolujte vazby portů. Záznam 0.0.0.0:PORT může být veřejně dosažitelný na hostitelích, kde není zablokován upstream Security group, externí firewall nebo pravidlo DOCKER-USER chain.
Vlastní bridge sítě jsou používány: Kontejnery na výchozím mostu Docker si navzájem komunikují bez omezení. Kontejnery na stejné uživatelské síti se mohou také vzájemně dosáhnout, takže oddělujte služby mezi samostatné sítě podle hranice důvěryhodnosti pro skutečnou izolaci.
Socket Docker není připojen v kontejnerech: Zkontrolujte soubory Compose a argumenty spuštění. Pokud se /var/run/docker.sock objevuje jako svazek, ověřte, že je to nezbytné a záměrné.
Základní image od ověřených vydavatelů s určenými verzemi: FROM ubuntu:latest stáhne nespecifikovanou, potenciálně zastaralou verzi. Připněte konkrétní release.
Žádné tajemství v souborech Docker, souborech Compose nebo argumentech buildu: Historie vrstev image si zachovává pověření i po smazání kontejneru. Použijte Compose secrets, Swarm secrets, build secret mounts nebo externí správce tajemství. Runtime proměnné prostředí jsou lepší než pevně zakódované hodnoty, ale stále se zobrazují ve výstupu inspect a v protokolech.
Plán opětovného buildu image definován: Staré image hromadí chyby zabezpečení. Měsíční frekvence rebuildu udržuje okno expozice na zvladatelné úrovni pro většinu nasazení.
Rozhraní pro správu chráněná ověřováním: Jakýkoli dashboard na veřejné IP adrese bez ověření je otevřeným vstupním bodem. Umístění v privátní síti je kde je to možné preferováno.
Logy kontejnerů jsou shromažďovány: Bez log pipeline závisí detekce incidentů na viditelném dopadu na systém. To je signál pro zásah, který přichází pozdě.
Závěr
Výchozí konfigurace Docker je navržena pro pohodlí, ne pro bezpečnost. Většina chyb popsaných v tomto článku pochází z nastavení, která nebyla nikdy změněna po počátečním nasazení, ne z sofistikovaných útoků.
Opravy jsou převážně jednorázová rozhodnutí o konfiguraci: direktiva USER, změna vázání portu, vlastní síť, plán rebuildu. Žádná z nich nevyžaduje nové nástroje pro většinu nasazení.
Správná konfigurace kontejneru je prvním úkolem. Infrastruktura, na které běží, je druhá. Obě záležitosti jsou důležité a ani jedna se nedá nahradit druhou.
