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.