Wenn "sicher" nur ein Bauchgefühl ist

Typisches Bild bei Istio-Audits: mTLS überall aktiviert, Dashboards grün, Compliance-Haken gesetzt.

Drei Stunden später steht fest: Niemand im Team kann verlässlich sagen, welche Services tatsächlich verschlüsselt kommunizieren. Das Setup ist “sicher” - nach Gefühl.

Kein Einzelfall. Das ist das Muster.

Istio wird eingeführt, um Sicherheit und Stabilität zu erhöhen. In der Praxis sehe ich regelmäßig das Gegenteil. Istio ist nicht das Problem. Die Einführung ist es: technisch gedacht, nicht strukturell.

Was das kostet:

Ein Engineer kündigt und mit ihm verschwindet das Wissen, wie Incidents im Mesh überhaupt analysiert werden. Bus-Faktor 1 als Geschäftsrisiko, das in keinem Risk Register steht.

Ein Auditor fragt, welche Traffic Policies wo greifen. Die Antwort dauert zwei Tage und ist am Ende nicht eindeutig.

Bei einem Production-Incident hängt die Time-to-Recovery davon ab, ob “der eine” gerade erreichbar ist.

Das eigentliche Problem ist selten die Konfiguration. Es ist fehlende Klarheit darüber, wer das Netzwerkverhalten im Cluster wirklich verantwortet, welche Regeln verbindlich gelten (und nicht nur dokumentiert sind), und ob ein Incident reproduzierbar analysiert werden kann oder an Personen hängt.

Ohne diese Grundlagen wird Istio mit jedem neuen Service riskanter, nicht sicherer.

Die Frage ist nicht, ob Istio richtig konfiguriert ist. Die Frage ist, ob das System dahinter skalierbar gedacht wurde - oder ob ihr gerade technische Schulden zertifiziert.

Welche Symptome erkennt ihr in eurem Setup wieder? Daraus mache ich die Themen für die nächsten Wochen.