Ein Gateway ist kein Sicherheitskonzept

Kaum liegt das Egress-Thema auf dem Tisch, kommt der Reflex: “Wir bauen ein Egress-Gateway, dann läuft alles über eine Stelle.” Beschlossen ist es oft, bevor jemand fragt, was es eigentlich erzwingen soll.

Es gibt gute Gründe für das Ding. Externe Partner pflegen IP-Allowlists, dann braucht ausgehender Traffic eine feste, bekannte Quelladresse. Oder Compliance verlangt eine zentrale Zone, in der ausgehender Verkehr inspiziert und protokolliert wird. Beides sind echte Anforderungen, beide löst ein Egress-Gateway sauber.

Nur: Dass Traffic durchs Gateway SOLL, steht in Routing-Regeln der Sidecars. Erzwungen ist damit nichts. Die Istio-Doku sagt es sinngemäß selbst: Das Mesh allein garantiert nicht, dass ausgehender Verkehr wirklich durchs Egress-Gateway läuft, dafür braucht es flankierende Mechanismen wie NetworkPolicies. Erst wenn das Cluster-Netz den direkten Weg nach draußen für alle Workloads dichtmacht und nur dem Gateway die Tür lässt, wird aus dem Routing ein Zwang.

Ohne diesen Riegel habt ihr ein Gateway, an dem man vorbeigehen kann. Das ist keine Kontrollinstanz, das ist Deko mit Betriebskosten.

Und die Betriebsseite gehört in dieselbe Rechnung: ein zusätzlicher Hop für jeden externen Call, eine Komponente, die Kapazität und Pflege braucht, und ein möglicher Single Point of Failure genau auf dem Pfad zu euren externen Abhängigkeiten.

Das Muster, das trägt: Egress-Gateway nur mit erzwungenem Pfad und einem Grund, der in einen Satz passt. Fehlt eins von beiden, ist REGISTRY_ONLY ohne Umweg (Post 16) die ehrlichere Architektur. Gleiche Inventur, ein Hop weniger, nichts vorgetäuscht.

Die Entscheider-Frage dazu hat zwei Teile: Was genau setzt euer Gateway durch? Und hat je jemand geprüft, ob man daran vorbeikommt? Erzählt gern, was bei euch im Pfad steht, Kontrollinstanz oder gewachsene Gewohnheit. Ich lese mit.