Erlaubt ist, was keiner verboten hat

Nach dem STRICT-Umbau aus der letzten Folge ist jede Verbindung im Mesh verschlüsselt und beidseitig authentifiziert. Klingt nach Ziel erreicht. Nur: Jeder Workload darf immer noch mit jedem reden.

mTLS beantwortet die Identitätsfrage. Autorisiert ist damit gar nichts. Solange keine AuthorizationPolicy existiert, lässt Istio jeden authentifizierten Aufruf durch. Der Abrechnungs-Service darf den Admin-Endpoint des Nachbarteams aufrufen, sauber verschlüsselt, mit gültigem Zertifikat. Das Audit-Log sieht vorbildlich aus, die Segmentierung fehlt trotzdem komplett.

Die Evaluationslogik in drei Schritten: Erst laufen CUSTOM-Policies (externe Autorisierung), dann alle DENY-Policies, dann die ALLOW-Policies. Trifft ein DENY, ist Schluss. Existiert für den Workload keine ALLOW-Policy, wird erlaubt. Existiert mindestens eine und keine passt, wird abgelehnt.

Im letzten Satz steckt das Muster: Eine leere ALLOW-Policy pro Namespace, ganz ohne Regeln, matcht nichts und dreht den Default damit auf Deny. Ab dann ist jeder erlaubte Pfad eine bewusste, lesbare Entscheidung. Die typische Falle geht andersherum: Wer nur DENY-Policies stapelt, verbietet Einzelfälle und hat weiter keinen Default. Alles ohne DENY-Treffer bleibt offen.

Die Ownership-Frage kennt ihr aus Post 4 und 6, sie gilt hier unverändert: Policies mit lokaler Wirkung gehören dem Tenant, der weiß, wer seinen Service rufen darf. Der mesh-weite Default gehört der Plattform.

Für Entscheider: Eine Firewall, die per Default alles durchlässt, würde im Netzwerk-Review niemand abnehmen. Im Mesh steht genau dieser Zustand oft jahrelang in Produktion, mit Compliance-Haken obendrauf.

Verboten ist, was jemand verboten hat. Der Rest läuft.

Ehrliche Frage in die Runde: Wie viele eurer Namespaces hätten heute schon eine Default-Deny-Policy, wenn ihr jetzt nachschaut?