Zabezpečení virtuálních serverů vs. Kubernetes

Při provozu aplikací na virtuálních systémech bylo jasné, že je nutné zabezpečit i samotné virtuální prostředí. Stá­le se totiž jedná o servery s vlastním operačním sys­té­mem a spoustou dalších komponent, které mohou být zranitelné nebo špatně nakonfigurované a mohou představovat snadný cíl pro útočníka. Proto i na aplikačních virtuálních serverech většina firem provádí pravidelný patch management a skenování zranitelností, zajišťuje bezpečnou konfiguraci těchto serverů, instaluje na ně EDR nebo jiné bezpečnostní technologie a hledá způsoby, jak ještě více takové servery zabezpečit. Často to není jednoduché vzhledem k provozovaným aplikacím, ale každý si uvědomuje, že systém, na kterém běží například srdce bankovního systému, musí být zabezpečený.

U kontejnerizovaných aplikací to už tak časté není. Velká část firem tuto technologii adoptuje, aniž zná rizika, která s kontejnerizací přichází. A nechávají tak Kubernetes nebo jiné kontejnerizační technologie nezabezpečené a ve stavu, kdy představují riziko pro bezpečnost dané infrastruktury.

Při implementaci Kubernetes totiž málo kdo přemýšlí nad tím, jak zajistí bezpečnost nodů, jakým způsobem bude identifikovat zranitelnosti v provozovaných kontejnerech nebo že by mělo být řešeno něco, co nazýváme image assessment.

Hrozby kontejnerizovaného světa

Svět kontejnerizovaných aplikací trpí stejnými bezpečnostními nedostatky, jaké známe z běžného IT prostředí. Kromě toho má však svá specifika, se kterými se pojí i hrozby specifické právě pro kontejnerizované prostředí. Ty nejzávažnější a nejběžnější si v následujících odstavcích popíšeme.

Container Escape

Princip kontejnerizovaných aplikací spočívá v tom, že aplikace samotná včetně všech potřebných knihoven pro běh je zapouzdřena do tzv. image, který je následně nezávislý na prostředí, ve kterém je spouštěn. Vše pro běh totiž samotný image obsahuje. Z takového image se pak velice jednoduše vytvoří běžící aplikace, tzv. kontejner. Kontejner je tedy běžící „virtuální oblast“, ve které samotná aplikace běží a je izolována od zbytku prostředí. Pokud je kontejner nevhodně navržen nebo spuštěn tak, že je příliš provázaný s host systémem, může se v případě kompromitace kontejneru útočník pokusit o únik z tohoto izolovaného prostředí a kompromitovat i host systém. Takový způsob úniku z kontejneru se v angličtině označuje jako technika container escape.

Zneužití takové slabiny umožňuje útočníkovi kompromitovat celý host systém, tedy worker node, na kterém kontejnerizované aplikace běží. Může se tak snadno dostat do ostatních aplikací, případně do jiných systémů v infrastruktuře, tedy provést lateral movement.

Tento útok předpokládá splnění dvou podmínek. První je, že se útočníkovi podařilo kompromitovat kontejner. Toho může dosáhnout publikováním image s vlastním škodlivým kódem, který je následně použit pro vytvoření aplikace. Další možností je vložení backdoor do některé z používaných knihoven, z poslední doby je znám incident s knihovnou xz-utils. Ke kompromitaci kontejneru může také dojít přes rozhraní aplikace, například v případě zranitelné webové aplikace může útočník zneužitím RCE zranitelnosti spustit škodlivý kód přímo v kontejneru a tím ho ovládnout.

Druhou podmínkou je zranitelnost nebo konfigurační chyba kon­tej­ne­ri­zo­va­né­ho prostředí, která umožňuje útočníkovi uniknout z kon­tej­ne­ru. Příkladem může být kontejner spuštěný v privilegovaném režimu, povolené mountování kritických adresářů host systému, nadbytečné tzv. capabilities (tedy specifická oprávnění pro provádění aktivit v host systému), nebo přítomnost a zneužití zranitelnosti kernelu, runtime prostředí jako je Docker nebo containerd nebo jiných komponent. Jednou z posledních takových zranitelností je skupina 4 zranitelností souhrnně označována jako Leaky Vessels.

Configuration drift

Kontejnery mají jednu specifickou vlastnost – jsou neměnné (v angličtině se používá pojem immutable). To znamená, že jakmile je kontejner nasazen, neměl by být měněn a jakékoliv další úpravy by měly být provedeny standardním procesem úpravy image a nasazení nového kontejneru. Tento princip bohužel není vždy vývojáři dodržován, což má negativní bezpečnostní dopad. Ačkoliv při nasazení kontejneru můžete mít jistotu, že je dostatečně zabezpečen (například se provádí image assessment), pokud se v průběhu kontejner změní, tato jistota je pryč.

Technika, kdy se mění z jakéhokoliv důvodu běžící kontejner a není dodržen princip neměnnosti, je označována jako configuration drift. Provedení neschválené změny v běžícím prostředí může mít za následek snížení bezpečnosti, protože může dojít k vytvoření nových zranitelností nebo jiných nedostatků. Tato technika není sama o sobě zneužitelná útočníkem, ale pokud se spoléháte na určité bezpečnostní standardy, které se při vývoji uplatňují, v případě změny běžícího kontejneru už nemusí být aplikovány. Do infrastruktury je tak možné zanést zranitelnosti, které bude velmi obtížné identifikovat.

Škodlivý kód v image

Další hrozba specifická pro kontejnerizovaný svět souvisí s image, ze kterých jsou následně kontejnery vytvářeny. K dispozici je spousta veřejných image databází (tzv. image registry), ze kterých je možné image stahovat. Tou nejznámější a nejpoužívanější je Docker Hub. Jedná se o systém, kde můžete ukládat již vytvořené image, ať už pro privátní použití, nebo je můžete zveřejnit všem uživatelům. Často si tak vývojáři usnadňují práci a například pokud potřebují image pro webový server, místo jeho vlastního sestavení si stáhnou ten, který je dostupný ve veřejném registru.

Takové veřejně dostupné image ale mají jeden zásadní nedostatek. Nemáte pod kontrolou jejich obsah. Může se tak poměrně snadno stát, že budete používat image, který obsahuje škodlivý kód nebo zranitelné knihovny. Pokud si neprovedete analýzu tohoto veřejně získaného image, nemáte jistotu, že je legitimní a bez nechtěných „vylepšení“.

Podle výzkumu společnosti JFrog z dubna 2024 ve veřejném registru Docker Hub více než 20 % image repozitářů obsahovalo škodlivý kód. Ve směs se jednalo o image, které měly průměrně v řádu tisíců nebo desetitisíců stažení. Můžeme se ale setkat i s takovými případy, kdy image obsahující škodlivý kód má více než dva miliony stažení. Jednalo se o image, který byl maskován jako legitimní nástroj pro správu databází. V neposlední řadě se na Docker Hub objevil oficiální image distribuce Alpine Linux, který ale neměl nakonfigurované heslo pro účet root. To umožňovalo útočníkovi po získání běžného neprivilegovaného účtu velice jednoduchý přístup právě k privilegovanému účtu root.

Únik secrets

Často se také můžeme setkat s případy, kdy jsou ve veřejných repozitářích nalezeny různá hesla nebo API klíče. Tento problém se netýká pouze zdrojového kódu na GitHub nebo jiných platformách, ale také zveřejněných image. Při nesprávném používání secrets, tedy při jejich hardkodování přímo do image, dojde v případě zveřejnění takového image i ke kompromitaci daných secrets. Pokud tedy vývojář nesprávně pracuje se secrets a image následně zveřejní (nebo se jiným způsobem dostane mimo vaši infrastrukturu), může se stát, že takto uniknou i credentials k databázím, mailovým serverům nebo jiným systémům. V roce 2023 bylo analyzováno téměř 400 000 image na Docker Hub a téměř 9 % z nich obsahovalo privátní klíče nebo API secrets.

Ochrana Kubernetes

Kontejnerizovaný svět přináší na jednu stranu spoustu výhod, ale nese s sebou i jistá rizika, která je nutná ošetřit a minimalizovat. Proto se v příštím díle podíváme na způsoby zajištění bezpečnosti kontejnerizované infrastruktury, analýzy veřejných i privátních image a identifikaci zranitelností, škodlivého kódu i sensitivních dat, ale také na ochranu běžících kontejnerů.

David Pecl Autor článku je Security Consultant ve společnosti Security Avengers.