Síťová bezpečnost kontejnerů: proč nestačí tradiční perimetrové firewally?

12. 2. 2025
Doba čtení: 5 minut

Sdílet

Autor: Depositphotos
S rostoucí popularitou Kubernetes se kontejnerová prostředí stávají klíčovou součástí IT infrastruktury. Tradiční přístupy k síťové bezpečnosti však často nestačí na zajištění potřebné ochrany v těchto dynamických prostředích.

Tradiční (a zastaralé) řešení síťové bezpečnosti kontejnerů

Co se dozvíte v článku
  1. Tradiční (a zastaralé) řešení síťové bezpečnosti kontejnerů
  2. Proč nestačí běžný perimetrový firewall
  3. Funkcionality kontejnerového firewallu
  4. Tradiční segmentace nestačí

V praxi se často setkáváme s tím, že síťová bezpečnost kontejnerů je i v produkčních prostředích omezená pouze na úroveň L3/L4 segmentace, bez jakékoliv hlubší inspekce provozu na L7 úrovni. Pro tento účel se typicky používají open-source nástroje typu Kubernetes Network Policies, které umožňují základní řízení přístupu na úrovni IP adres a portů. Představit si to lze v podstatě jako access-list na routeru, který provádí filtrování provozu pouze na úrovni IP hlaviček, TCP segmentů nebo UDP datagramů, což znamená absenci hlubší kontroly a pochopení toho, jaký typ aplikace nebo protokolu provoz představuje.

Další problém představuje logování síťového provozu kontejnerů, protože většina síťových pluginů typu CNI (např. Flannel nebo Calico v základním režimu) neposkytuje detailní logy na úrovni L7, jako to dokáže firewall. Tento nedostatek ztěžuje nejen detekci a analýzu bezpečnostních incidentů, ale také splnění auditních požadavků a dodržování regulací, jako jsou GDPR nebo PCI DSS.

Proč nestačí běžný perimetrový firewall

Pokud Kubernetes cluster běží za standardním perimetrovým firewallem, je nutné počítat se dvěma zásadními limity: 

  1. Perimetrový firewall nevidí do komunikace kontejnerů v případě, že kontejnery komunikují mezi sebou uvnitř clusteru v rámci stejného nodu (v mnoha případech platí i pro komunikaci mezi různými nody).
  2. Perimetrový firewall není schopný rozeznat síťový provoz jednotlivých kontejnerů, pokud se tento provoz na firewall vůbec dostane.

Pokud na jednom nodu běží více komponent aplikace, například ordering payments, jejich vzájemná komunikace se odehrává uvnitř nodu a nikdy se nedostane na perimetrový firewall. To znamená, že taková komunikace nemůže být skenována a případně blokována externími bezpečnostními nástroji, jako je právě perimetrový firewall. To stejné platí v případě, že veškeré nody z jednoho clusteru jsou ve stejné sítí.

Pokud cluster běží v různých datacentrech nebo v cloudu, tak komunikující nody mohou provádět enkapsulaci (např. VXLAN), čímž ale dochází k obfuskaci skutečné IP adresy podu, což může představovat problém pro aplikování bezpečnostních politik na úrovni jednotlivých podů. Overlay sítě, jako je VXLAN, nejen skrývají skutečné IP adresy podů, ale přidávají také enkapsulaci paketů, což je třeba brát v potaz v případě, kdy by fragmentace paketů mohla představovat problém.

Pokud pod komunikuje do externích sítí, jako např. internet, komunikace se NATuje za IP adresu nodu, na kterém daný pod běží. Nelze tak snadno rozeznat např. kompromitovaný kontejner, který komunikuje s C2 serverem útočníka, protože tato komunikace může pocházet z kteréhokoliv nodu, na kterém pod běží.

Kvůli těmto nedostatkům vznikly kontejnerové firewally, které se integrují dovnitř Kubernetes clusterů.

Funkcionality kontejnerového firewallu

Práce s Kubernetes metadaty

Moderní kontejnerové firewally rozumí Kubernetes metadatům, jako jsou například labely a namespacy, tudíž lze konfigurovat bezpečnostní politiky a inspekci provozu pomocí těchto prvků.  Firewall tyto informace získává prostřednictvím Kubernetes master nodu a pomocí nich umí vytvořit objekty, které jsou na tyto labely nebo namespacy namapované. Takto si firewall vždy udržuje aktuální IP adresaci podů tím, že ji automaticky změní v momentě, kdy se změní IP adresa podu.

Toto řešení umožňuje udržovat bezpečnostní politiky aktuální, protože reflektují skutečný stav objektů. Kontejnery jsou „od přírody“ dynamické a dochází k tomu, že se automaticky vytvářejí a mažou, např. z důvodu škálovatelnosti. IP adresace podů se tak mění, což může při aplikaci bezpečnostní politiky představovat problém. Zmíněná metadata tak značně ulehčují konfiguraci bezpečnostních politik, jelikož si podle nich firewall sám vytvoří tyto objekty a není potřeba je konfigurovat ručně.

L7 Mikrosegmentace

Současný přístup ke kontejnerové bezpečnosti klade důraz na tvorbu bezpečnostních politik založených na L7 aplikacích či protokolech, nikoliv pouze na IP adresách a číslech portů. Jednou z devíz kontejnerového firewallu je to, že zpřístupňuje Zero Trust architekturu uvnitř Kubernetes clusteru. Díky tomu lze izolovat a skenovat provoz jednotlivých komponent aplikace.

V bezpečnostním pravidle tak například nepoužijeme port 80 pro povolení HTTP, ale specifikujeme konkrétní aplikaci, v tomto případě web-browsing. Tím docílíme toho, že povolujeme skutečně HTTP provoz, nikoliv jakýkoliv provoz na portu 80, jako je to v případě Kubernetes Network Policies. Zároveň je možné povolit provoz pouze pro konkrétní API endpoint v rámci aplikace (např. /api/login) místo obecného pravidla, které povoluje veškerý provoz na portu 443.

Viditelnost a reportování

Pokud používáte běžné open-source nástroje, například Calico nebo Kubernetes Network Policies, a někdo se vás zeptá, jaké aplikační protokoly či na které webové aplikace (např. GitHub) komunikují konkrétní pody, tak asi nebudete schopni snadno odpovědět, protože tyto nástroje takovou funkcionalitu neumožňují. 

Kontejnerový firewall nejenom umožní získat přehled o tom, jaký provoz běží v kontejnerových prostředích, ale zároveň dokáže odhalit neobvyklé vzorce provozu, například přístup z některých podů na podezřelé domény.

Centralizovaný management

V některých případech se kontejnerové firewally integrují přímo na management server, který spravuje i veškeré ostatní firewally (včetně těch tradičních), což umožňuje jednodušší správu standardních i kontejnerových prostředí z jedné konzole. Někdy je možné do tohoto centralizovaného managementu posílat rovnou i logy z kontejnerových firewallů, tudíž vznikne i centralizovaná správa logů, se kterou se snadno pracuje. Tím, že jsou v managementu k dispozici i logy, je možné vytvářet reporty, např. kdo kdy a kam komunikoval na jakém protokolu a kolik dat proteklo. 

Automatizace

Kontejnerové firewally samozřejmě berou v potaz i automatizaci, tudíž lze očekávat podporu Terraform a Helm Charts. Díky podpoře Terraform je tak možné nasazovat firewall společně s aplikací v rámci CI/CD pipeline.

Tradiční segmentace nestačí

V současnosti na trhu existuje již několik kontejnerových firewallů od různých dodavatelů, například Juniper, Palo Alto Networks nebo Check Point. S rostoucí složitostí kontejnerových prostředí a jejich významem pro moderní IT infrastrukturu se zajištění odpovídající síťové bezpečnosti stává klíčovým úkolem.

Tradiční přístupy založené na L3/L4 segmentaci již často nestačí, a proto vznikají moderní nástroje, jako jsou kontejnerové firewally, které umožňují pokročilou inspekci provozu, dynamickou správu bezpečnostních politik a lepší viditelnost v rámci Kubernetes clusterů.

Pokud ve své infrastruktuře narážíte na limity současných řešení, jako je nedostatečné logování, absence pokročilého skenování kontejnerového provozu, nemožnost identifikovat konkrétní pody nebo obtíže při přizpůsobování bezpečnostních politik dynamickým změnám v clusteru, může být užitečné podívat se na možnosti, které tyto nástroje nabízejí.

 Díky schopnostem jako práce s Kubernetes metadaty, L7 mikrosegmentace a inspekce, centralizovaná správa a podpora automatizace se kontejnerové firewally stávají nedílnou součástí moderních bezpečnostních strategií.

Autor článku

Pracuje ve společnosti ANECT a má rozsáhlé zkušenosti v oblasti sítí a síťové bezpečnosti v oblasti soukromého i veřejného sektoru s využitím řady technologií platforem, například Cisco, Palo Alto, Juniper, Fortinet, F5 a další. Je držitelem několika certifikací, včetně CISSP, CCSP, PCNSE, PCSFE, CCNA a dalších.