Názory k článku Síťová bezpečnost kontejnerů: proč nestačí tradiční perimetrové firewally?

Úvod do problematiky je to pěkné, díky za prima článek.
Plánujete pokračování?

Spis mi prijde, ze autor sepsal PR clanek na produkt a zapomnel prilozit odkaz :D

to je jako by nekdo v roce 2001 popsal zakladni funkcionality switche a ze ma vyhody oproti hubu napr. to ze vytvari kolizni domeny na kazdem spojeni a umi vlany a nekdo by k tomu pak napsal ze to je pr clanek na produkt :D makes sense

ani z jejich stránek anect.com jsem se nedozvěděl, které kontejnerové firewally vlastně mají na mysli, ale z článku jistojistě vím, že je prostě potřebuji.

No, já se z toho webu nedozvěděl teda vlastně vůbec nic krom úžasných úderných hesel jako "Innovate or Die". 🤣

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.

To opravdu umožňuje filtrovat podle obsahu provoz skrytý uvnitř SSL?
Nebo je uvedené číslo portu chyba?

Muze jit o starou znamou "profi firewallovou" fintu, kdy "firewall" generuje certifikaty on the fly a vybaluje/znovu zabaluje TLS provoz.
Zajimave cteni ma treba v dokumentaci Cilium: https://docs.cilium.io/en/stable/security/tls-visibility/
Samozrejme, jak tu popsal kolega niz, v kombinaci s mTLS to nejspis dobre fungovat nebude.

jedná se o interní síť, pro "kontejnerový firewall" bude obsah viditelný případně bude sloužit jako gateway, kdy přes něj celý provoz bude putovat, tak to obvykle i děláme. Spravidla to spojuješ s nějakou možností dynamického směřování route či úrovní zabezpečení (jwt a jiné tokeny, které validuješ). To tím asi básník chtěl říct.

Např. v případě Google cloudu se jedná o službu Secure Web Proxy, která má k dispozici TLS klíče. Pro K8s je třeba možné použít Cilium a jeho gateway API, jak zmiňuješ, opět buď jí necháš generovat TLS nebo jí je dáš k dispozici.

Pak je tady spoustu http reverzních proxy, které si k tomu můžeš použít a dynamicky je konfigurovat z venku. Já si docela oblíbil používat spnego s granualitou na samotné path (api endpointy), výhoda je, že se to dá škálovat do šířky na desítky GB/s.

E2E šifrování v případě interních mikroslužeb nedává smysl, ty potřebuješ řídit a kontrolovat vlastní infrastrukturu, nelze do vnitřních systému připojit kohokoliv jen podle portu a pak mu říct, ať si tam dělá cokoliv. Stejně tak nechceš mít veřejné TLS certifikáty uvnitř. Zpravidla ukončuješ veřejné TLS spojení někde na bráně, vstupu do infrastruktury a vnitřně jedeš už na svých TLS.

Jsem zvědavý na pokračování. Zatím na mě článek působí neúplně. Popisovaný čistý k8s cluster jsem neviděl dlouho, proto mě víc zajímá přínos oproti service mesh ala istio a samozřejmě integrace s nimi. On ten firewall do komunikace mezi pody nemusí vidět nejen kvůli komunikaci v rámci hostu, ale třeba kvůli enforced mtls. Na druhou stranu s mtls chodí metadata o podu a funguje autorizace podle servisních účtů nebo http metadat.

vzhledem k tomu, že v článku vlastně nic nenapsal, tak klidně mohl mluvit o istio.

Mně třeba na Istio nejvíce vadí, že to je vše příliš hardcodované, nemám tam podporu pro nějaký katalog služeb, api, nemáme tam ucelený přehled kdo tam může, vše je přímo hozeno do policies. Ano, je tady sice Kiali, přehled jakžtakž, ale service wizard je šílenost.

Zaměřuji se primárně na zabezpeční a právě i Istia mi hodně vadí, že detekce podezřelého chování, jeho izolace či odklonění a ověření je extrémně krkolomné, náročné a neefektivní. Po nějaké době provozu se tam nahromadí hromada smetí v policies a není možné snadno ověřit, co vlastně způsobí změna konfigurace, který aktuální provoz se tím ovlivní a jak.

Jak znám Honzu, autora, tak to směřuje k https://www.paloaltonetworks.com/network-security/cn-series

Článek je dobrý, ale bohužel poněkud povrchní. Pravidla na vrstvě L7 jsou v tomto případě nutností, ale to stejné platí pro load balancing či rozdělení obsahu pro CDN. To vše začíná u Microservices Architecture, BTW povedená kniha.