Der Schalter, den keiner zuerst umlegen will

“mTLS ist aktiviert”, sagt das Team. Auf Nachfrage steht der Mesh-Default seit der Einführung auf PERMISSIVE. Das ist kein Aktiviert. Das ist ein Vielleicht.

PERMISSIVE heißt: Der Sidecar nimmt mTLS an, Klartext aber auch. Als Migrationszustand ist das genau richtig, niemand will bei der Einführung die halbe Landschaft abreißen. Als Dauerzustand heißt es Verschlüsselung “meistens”. Wie viel Klartext noch unterwegs ist, weiß keiner. Post 1 lässt grüßen: sicher nach Gefühl.

Der Weg auf STRICT ist kein Mutsprung, sondern ein Messvorgang.

Erst beobachten: istio_requests_total führt das Label connection_security_policy mit. Eine Abfrage, und ihr seht, welche Verbindungen noch ohne mutual_tls laufen. Dieselbe Telemetrie wie in Post 9, diesmal als Migrations-Radar.

Dann stufenweise scharf stellen: PeerAuthentication mit mode: STRICT zuerst pro Workload oder Namespace, dort, wo die Metrik null Klartext zeigt. Hängt doch noch ein Legacy-Client dran, fällt er einzeln auf statt im großen Knall. Mesh-weit kommt der Schalter zum Schluss, wenn die Restliste leer ist. Und der Rollback-Pfad ist benannt, bevor irgendwer schaltet: das PeerAuthentication zurück auf PERMISSIVE, ein Apply, kein Redeploy.

Für die Entscheider-Seite ist der Unterschied größer, als er klingt. “Verschlüsselung ist eingestellt” ist eine Absichtserklärung. “Klartext ist technisch unmöglich, hier ist die Metrik” ist ein Nachweis. Ein Auditor fragt genau nach dem zweiten Satz.

Wer bei PERMISSIVE stehen bleibt, hat den Umzugskarton nie ausgepackt und nennt die Wohnung eingerichtet.

Eine Baustelle bleibt danach trotzdem offen: mTLS klärt sauber, WER da redet. Es sagt kein Wort darüber, wer reden DARF. Dazu nächste Woche.