Vlákno názorů k článku Síťová bezpečnost kontejnerů: proč nestačí tradiční perimetrové firewally? od Honza K. - Zároveň je možné povolit provoz pouze pro konkrétní...
-
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.
