Nejčastější chyby zabezpečení Dockeru, kterým je třeba se v roce 2026 vyhnout

Docker můžete provozovat v produkci měsíce bez viditelného problému. Kontejnery se spustí, aplikace reagují, nic se nerozbije. Pak jeden odhalený port nebo jedno špatně nakonfigurované oprávnění vytvoří oporu, kterou si útočník nemusel vydělat. Většina bezpečnostních chyb Dockeru nevypadá jako chyby, dokud se něco nepokazí.

Tento článek pojednává o konkrétních konfiguracích, které ohrožují prostředí kontejnerů, o tom, co každá z nich umožňuje útočníkovi, a uzavírá kontrolní seznam, který můžete dnes spustit proti vlastnímu nastavení.

Proč je zabezpečení Dockeru těžší, než se zdá

Kontejnery se cítí izolované. Spustíte jeden, spustí svůj vlastní procesní prostor a z něj další kontejner neexistuje. Získáte izolaci, ale je to jen částečná. Kontejnery sdílejí jádro hostitele, což znamená, že proces uvnitř kontejneru může za určitých podmínek zcela dosáhnout hostitelského systému.

Dockerské lodě jsou nakonfigurovány pro pohodlí vývojářů, nikoli pro zpevnění výroby. Zapnut root přístup. Všechny porty lze svázat se všemi rozhraními. Žádné sledování běhu. Většina vývojářů tato nastavení akceptuje, odešle kontejner a pokračuje. To je rozumný přístup pro začátek; není to hotová bezpečnostní pozice.

Podle Zpráva společnosti Red Hat o stavu zabezpečení Kubernetes za rok 202467 % organizací zpozdilo nebo zpomalilo nasazení aplikací kvůli obavám o zabezpečení kontejnerů nebo Kubernetes. Toto tření obvykle nepochází z útoků. Je to od týmů, které zjistily, že jejich nastavení kontejnerů potřebují zpevnění, které nezabudovaly.

Často vidíme, že kontejnery běží ve výrobě se stejnou konfigurací, jakou měli na lokálním počítači vývojáře. To je místo, kde se bezpečnostní chyby Dockeru tiše množí, bez viditelných příznaků, dokud není něco auditováno nebo selže.

Chyby, které vytvářejí tyto mezery, jsou specifické, předvídatelné a většinou se jim lze vyhnout, počínaje úrovní konfigurace.

Běžné chyby konfigurace Dockeru

Většina porušení kontejnerů nezačíná zneužitím zero-day. Začínají s konfigurací nastavenou v první den, bez velkého přemýšlení o vystavení sítě nebo rozsahu oprávnění.

Výchozí nastavení Dockeru jsou vytvořena tak, aby fungovala. Propast mezi funkčním a bezpečným je místem, kde se hromadí bezpečnostní rizika kontejnerů Docker, zejména v nastaveních s vlastním hostitelem, která jsou nasazena a nikdy se nevrátí.

S tímto vzorem se setkáváme často: kontejnery na serverech s veřejnou IP s vazbou portů, uživatelskými nastaveními a konfiguracemi sítě přesně tak, jak byly při počátečním nasazení.

Spuštěné kontejnery jako kořen

Když spustíte kontejner Docker bez určení uživatele, spustí se jako root. To znamená, že jakýkoli proces uvnitř kontejneru, včetně vaší aplikace, má oprávnění na úrovni root v rámci jmenného prostoru kontejneru.


Root uvnitř kontejneru není totéž jako root na hostiteli, ale oddělení není absolutní. Zneužívání eskalace privilegií zacílené na běhové prostředí, jako je dobře zdokumentovaný runc CVE-2019-5736 a podobné chyby běhového prostředí, často k úspěchu vyžadují proces kořenového kontejneru.

Nekořenové kontejnery odstraňují požadavek na kořenový proces, na kterém tyto exploity závisejí, a výrazně zužují plochu útoku pro tuto třídu zranitelnosti, i když riziko úniku kontejneru zcela neodstraňují.

Přidání direktivy USER do vašeho Dockerfile to řeší. Některé oficiální obrázky jsou dodávány s neprivilegovaným uživatelem, kterého můžete aktivovat pomocí direktivy USER, ale mnoho z nich je stále ve výchozím nastavení root bez připraveného uživatele aplikace. V těchto případech vytvoříte uživatele v Dockerfile před přepnutím na něj. U většiny nastavení s vlastním hostitelem tato jediná změna odstraňuje celou kategorii rizika eskalace.

Vystavení příliš mnoha portů veřejnému internetu

Když publikujete port pomocí Dockeru, Docker zapíše přímo vlastní pravidla iptables. Tato pravidla běží před pravidly brány firewall na úrovni hostitele. Toto je a dobře známé chování hlášené komunitou a dokumentováno v Dockerově průvodci filtrováním paketů, nejde o nesprávnou konfiguraci a znamená to, že UFW a podobné nástroje neblokují to, co Docker již otevřel.

Docker zapisuje přímo do iptables, čímž obchází výchozí nastavení UFW a firewallu na mnoha hostitelích Linuxu. To znamená, že port vázaný na 0.0.0.0 může být veřejně dosažitelný, i když se váš firewall jeví jako nakonfigurovaný. Skupiny zabezpečení cloudu a pravidla řetězce DOCKER-USER mohou stále blokovat tento provoz, takže skutečné vystavení závisí na vašem konkrétním nastavení sítě.

Pokud je to možné, spojte služby s 127.0.0.1, směrujte veřejný provoz přes reverzní proxy a publikujte pouze to, co skutečně vyžaduje externí přístup. Reverzní proxy je nejspolehlivějším způsobem kontroly toho, co je vystaveno zvenčí hostitele.

Ignorování síťové izolace mezi kontejnery

Jakýkoli kontejner v této síti může dosáhnout jakéhokoli jiného kontejneru v této síti bez omezení. Výchozí most nepoužívá žádné filtrování provozu mezi kontejnery, které jej sdílejí, a většina nastavení tuto konfiguraci nikdy nezmění.

Pokud dojde ke kompromitaci jednoho kontejneru, tato otevřená komunikace se stane cestou bočního pohybu. Frontendový kontejner může dosáhnout databáze, interního rozhraní API nebo čehokoli jiného ve stejné výchozí síti mostu, i když tento přístup nebyl nikdy zamýšlen.

Uživatelsky definované sítě vám dávají explicitní kontrolu nad tím, které kontejnery mohou komunikovat, ale jediná vlastní síť sdílená všemi vašimi službami stále umožňuje bezplatný provoz mezi kontejnery. Skutečná izolace vyžaduje umístění služeb, které by spolu neměly mluvit, do samostatných sítí. Vypnutí výchozího mostu je výchozí bod, nikoli cílová čára.

S výhledem na Docker Socket

Soket Docker na adrese /var/run/docker.sock je ovládacím rozhraním pro celý engine Docker. Připojením do kontejneru poskytnete tomuto kontejneru přímý přístup API k démonu běžícímu na hostiteli.

Díky tomuto přístupu může kontejner spouštět nové kontejnery, připojovat hostitelské adresáře, kontrolovat a upravovat běžící kontejnery a efektivně ovládat hostitelský počítač. Útočná plocha je ekvivalentní rootu na hostiteli, a proto si každý nástroj, který vyžaduje přístup k soketu, zaslouží pečlivé vyhodnocení.

Pro většinu případů použití existují bezpečnější alternativy: API s rozsahem nebo Nástroje pro správu dockeru které nevyžadují přístup k zásuvce. Docker-in-Docker má své vlastní bezpečnostní a provozní kompromisy a není přímou náhradou.

Chyby konfigurace vytvářejí počáteční expozici. Volby obrazu a závislosti určují, jak se tato expozice v průběhu času složí.

Chyby v obraze a tajemství, které přežijí kontejner

Když kontejner zastavíte, konfigurační chyby v něm se zastaví spolu s ním. Při opětovném sestavení z bitové kopie, která nese chybu zabezpečení nebo pevně zakódované pověření, se problém znovu spustí s kontejnerem. Chyby na úrovni obrázku se mezi nasazeními neresetují.

Cestují s obrazem do každého prostředí, které jej stahuje, do každého registru, který jej ukládá, a do každého člena týmu, který jej provozuje. Díky této vytrvalosti je správa obrázků a tajemství samostatnou kategorií rizik, která stojí za to auditovat odděleně od konfigurace.

S tímto vzorem se setkáváme často: obrázek pečlivě vybraný na začátku projektu a od té doby nikdy přestavěný, pomalu se vzdalující od základní bezpečnostní linie, kterou zpočátku představoval.

Používání nedůvěryhodných nebo zastaralých obrázků

Veřejné rejstříky jsou otevřené komukoli. Škodlivé obrázky byly distribuovány prostřednictvím Docker Hub s kryptoměry a zadními vrátky začleněnými do historie vrstev, které přetrvávají po restartování kontejneru. Ověření před stažením záležitostí, zejména u obrázků od neoficiálních nebo neznámých vydavatelů.

Samostatným problémem je zatuchlost. Oficiální obrázek, který jste stáhli před šesti měsíci a od té doby jste jej nikdy nepřestavěli, hromadí neopravené zranitelnosti Dockeru s každým CVE odhaleným proti jeho balíčkům. Obrázek není rozbitý. Jen už to není aktuální.

Zpráva společnosti Sonatype o stavu softwarového dodavatelského řetězce za rok 2024 zjistili, že v 95 % případů, kdy je zranitelná součást spotřebována, je již k dispozici pevná verze a 80 % závislostí aplikací zůstává déle než rok neaktualizovaných. Tento vzor je relevantní i pro základní obrazy Docker, protože se spoléhají na stejné balíčky s otevřeným zdrojovým kódem.

Používejte oficiální obrázky od ověřených vydavatelů a připněte si značky konkrétní verze, místo abyste se spoléhali na „nejnovější“. Vytvořte si pravidelnou kadenci přestavby, aby byly vaše snímky aktuální.

Tajemství pevného kódování v souborech Dockerfiles a Compose Files

Přihlašovací údaje zapsané do instrukce ENV nebo ARG Dockerfile, pevně zakódované do bloku prostředí Compose, předané jako argumenty sestavení nebo uložené v souboru .env zavázaném ke kontrole verzí, když kontejner zastavíte, nezmizí. Zůstávají v historii vrstvy obrazu nebo v ovládacím prvku zdroje a jsou přístupné komukoli, kdo je může dosáhnout.

Toto je jedna z nejvíce přehlížených bezpečnostních chyb Dockeru, protože během vývoje nezpůsobuje viditelné problémy. Klíč API v instrukci ENV funguje správně. Je také ve vašem úložišti, zapečetěn do vašeho obrazu a distribuován všude tam, kde se obraz pohybuje.

Modern Docker Compose podporuje nativní mechanismus tajných klíčů, který připojuje přihlašovací údaje za běhu, aniž by je vkládal do obrazu. Rozhraní API Docker’s secrets a správci externích tajemství se řídí stejným principem. Toto jsou možnosti, které udržují přihlašovací údaje zcela mimo artefakty sestavení a potvrzené soubory.

Proměnné běhového prostředí jsou vylepšením oproti pevně zakódovaným přihlašovacím údajům, ale stále jsou vystaveny prostřednictvím inspekce výstupu Docker, protokolů a výpisů zhroucení. Jsou o krok výš od zapečených tajemství, nikoli o hotové řešení.

Neaktualizuje obrázky kontejnerů pravidelně

Běžet měsíce se stejným obrazem je běžný zvyk. Každý den, který uplyne po odhalení nové zranitelnosti, ale před přestavbou mají vaše kontejnery okno expozice, které roste bez jakékoli viditelné změny.

Sestavte konzistentní plán přestavby. Automatizujte tento proces, kde je to možné, a pravidelně spouštějte skener zranitelnosti proti vašim aktuálním obrázkům. Cílem není dokonalost. Zkracuje dobu mezi vydáním opravy a jejím nasazením.

Řízení přístupu a monitorování mohou být při rychlém nasazení zbaveny priority. Jsou to také kategorie, kde incidenty zůstávají neodhaleny nejdéle.

Kontrola přístupu a mezery ve viditelnosti

Po spuštění kontejneru s pevnou konfigurací a aktuálními obrazy zůstávají dvě kategorie selhání. Oba jsou ze své podstaty neviditelné: nevšimnete si slabého problému s řízením přístupu, dokud to někdo nepoužije, a nevšimnete si mezery v monitorování, dokud nebudete muset prozkoumat aktivitu, která nebyla nikdy zaznamenána.

To samé Výzkum Red Hat 2024 zjistili, že 42 % týmů postrádalo dostatečné schopnosti k řešení zabezpečení kontejnerů a souvisejících hrozeb.

Zjistili jsme, že mezery v monitorování se obvykle objevují během vyšetřování incidentů, nikoli dříve. V době, kdy se viditelnost stane prioritou, často na něco reaguje, než aby tomu bránila.

Slabé řídicí panely pro ověřování a odhalenou správu

Řídicí panel pro správu kontejnerů na veřejné IP bez ověřování nevyžaduje sofistikovaného útočníka. Vyžaduje, aby znali adresu. To je nižší laťka, než si většina týmů uvědomuje.

Samoobslužné nástroje pro monitorování a správu se obvykle dodávají s webovým rozhraním přístupným na všech síťových rozhraních. Ponechat ty na veřejné IP bez auth před nimi je ekvivalentní kontejneru, jako nechat odemčený administrátorský panel.

Základem je autentizace, reverzní proxy a umístění privátní sítě. Řízení přístupu je konfigurační krok, který přidáte do libovolného rozhraní pro správu, nikoli něco, co se dodává povolené.

Stejný princip platí pro Docker CLI a správa GUI; Přístup k démonu na úrovni správce nese stejné riziko bez ohledu na rozhraní.

Nesledujete, co dělají vaše kontejnery

Pokud je kontejner kompromitován, aktivita útočníka vytvoří stopu: změny chování procesu, neobvyklá síťová připojení a neočekávané úpravy souborů. Bez shromažďování protokolů tato stezka neexistuje ve formě, podle které byste mohli jednat.

Centralizované shromažďování protokolů, protokolování auditu kontejnerů a nástroje pro monitorování za běhu vám poskytnou data pro detekci abnormální aktivity dříve, než se sloučí. Cílem není analyzovat každý řádek. Má k dispozici data, když je potřebujete prozkoumat.

Nastavení kontejnerů, která běží tiše v produkci bez potrubí protokolů a bez výstrah, nejsou nenáročná na údržbu. Jsou bez kontroly. To jsou dva různé provozní stavy.

Proč je také důležité prostředí infrastruktury

Zabezpečení kontejneru začíná konfigurací, ale konfigurace běží nad infrastrukturou. Hostitel s nesprávně 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 samostatné úkoly.

Mnoho mezer v zabezpečení Dockeru je umocněno podmínkami, které kontejnery samy zdědí:

• Server sdíleného pronájmu bez hardwarové izolace mezi tenanty
• Hostitelské jádro běží bez záplaty
• Hostitel bez vestavěného filtrování na úrovni sítě

Tím není odstraněna potřeba výše uvedených konfiguračních kroků, protože na správném zpevnění kontejneru záleží bez ohledu na vrstvu infrastruktury. Začátek na izolované infrastruktuře odstraňuje jednu vrstvu obav z rovnice.

V Cloudzy nabízíme dvě cesty v závislosti na tom, co vaše nastavení vyžaduje:

• Linux VPS: čisté prostředí pro vlastní nasazení Dockeru a použití kroků zpevnění v tomto článku
• Porttainer VPS: možnost jedním kliknutím s předinstalovaným Portainerem; server se spustí a vy jste již v řídicím panelu

Obě možnosti běží na stejné infrastruktuře: virtualizace KVM, procesory AMD Ryzen 9 s taktem až 5,7 GHz, paměť DDR5, úložiště NVMe SSD, síť až 40 Gb/s a bezplatná ochrana DDoS prostřednictvím filtrování BuyVM ve 12 globálních lokalitách s 99,95% dostupností SLA.

Pro hlubší pohled na spouštění Porttaineru na VPS se mu věnujeme ve vyhrazeném článku.

Praktický kontrolní seznam zabezpečení pro nasazení Dockeru

Výše uvedené bezpečnostní chyby Dockeru většinou pocházejí z jednoduchých rozhodnutí o konfiguraci, která byla učiněna jednou a nikdy nebyla znovu navštívena. Spuštění tohoto kontrolního seznamu s existujícím nastavením tyto mezery zachytí. Funguje jako audit, nikoli jako průvodce nasazením.

Tyto osvědčené postupy zabezpečení Dockeru pokrývají, jak zabezpečit kontejnery Docker proti nejčastějším selháním konfigurace popsaným výše.

Rychlý průvodce: Všech 9 chyb

Doporučujeme jej nejprve spustit se stávajícími nastaveními, protože právě tam jsou mezery s největší pravděpodobností již přítomny.

Kontejnery běžící jako non-root: Zkontrolujte, zda vaše Dockerfiles neobsahuje direktivu USER. Pokud žádný neexistuje, kontejner běží jako root.

Vazby portů omezené na localhost nebo proxy: Spusťte docker ps a zkontrolujte vazby portů. Položka 0.0.0.0:PORT může být veřejně dostupná na hostitelích, kde ji neblokuje žádná nadřazená bezpečnostní skupina, externí firewall nebo řetězové pravidlo DOCKER-USER.

Používané vlastní mostové sítě: Kontejnery na výchozím můstku Dockeru se k sobě mohou volně dostat. Kontejnery na stejném uživatelsky definovaném mostu spolu mohou stále komunikovat, takže pro skutečnou izolaci rozdělte služby mezi samostatné sítě podle hranice důvěryhodnosti.

Docker zásuvka není namontována v kontejnerech: Zaškrtněte volbu Vytvořit soubory a spustit argumenty. Pokud se /var/run/docker.sock objeví jako svazek, potvrďte, že je to povinné a záměrné.

Základní obrázky od ověřených vydavatelů s připnutými verzemi: FROM ubuntu:latest stahuje blíže nespecifikovanou, potenciálně zastaralou verzi. Připnout ke konkrétnímu vydání.

Žádná tajemství v Dockerfiles, Compose files nebo build argumenty: Historie vrstvy obrázků uchovává přihlašovací údaje i po smazání kontejneru. Použijte Compose secrets, Swarm secrets, stavte tajné mounty nebo externího správce tajemství. Proměnné běhového prostředí jsou lepší než pevně zakódované hodnoty, ale stále se objevují ve výstupu kontroly a protokolech.

Definován plán obnovy obrázku: Staré obrázky hromadí zranitelnosti. Měsíční kadence přestavby udržuje okno expozice zvládnutelné pro většinu nastavení.

Rozhraní pro správu za autentizací: Jakýkoli řídicí panel na veřejné IP bez ověření je otevřeným vstupním bodem. Kde je to možné, je preferováno umístění privátní sítě.

Shromažďují se protokoly kontejnerů: Bez potrubí protokolů závisí detekce incidentů na viditelném dopadu systému. To je pozdní signál, podle kterého je třeba jednat.

Závěr

Výchozí konfigurace Dockeru je vytvořena pro pohodlí, nikoli pro zabezpečení. Většina chyb popsaných v tomto článku má původ v nastaveních, která nebyla po počátečním nasazení nikdy změněna, nikoli po sofistikované útoky.

Opravy jsou většinou jednorázová konfigurační rozhodnutí: direktiva USER, změna vazby portu, vlastní síť, plán přestavby. Žádný z nich nevyžaduje nové nástroje pro většinu nastavení.

Správná konfigurace kontejneru je prvním úkolem. Infrastruktura, na které běží, je druhá. Obojí je důležité a ani jedno nenahrazuje druhé.

FAQ