Zertifikate altern schneller als Runbooks

Die Workload-Zertifikate in eurem Mesh sind kurzlebig und rotieren automatisch. Seit Jahren, ohne dass jemand hinschaut. Genau deshalb schaut auch auf den Rest der Kette niemand mehr.

Über den Workload-Zertifikaten hängt nämlich eine Vertrauenskette: eine Root-CA, oft ein Intermediate darunter, und erst ganz unten das Kurzlebige. Die oberen Glieder rotieren nicht von selbst. Ihr Ablaufdatum wird in Produktionsjahren gemessen, weit jenseits jeder Teamfluktuation.

Beim Default-Install erzeugt sich Istio seine CA selbstsigniert einfach selbst. Praktisch für den Start, und genau da beginnt das Problem: Diese CA taucht in keinem Zertifikats-Inventar der Organisation auf, weil sie nie durch einen offiziellen Prozess gelaufen ist. Drei Fragen als Test: Wer kennt das Ablaufdatum? Wo steht der Rotationsplan? Wurde die Rotation je geübt statt nur beschrieben?

Die Sichtprüfung kostet eine Minute, das Werkzeug kennt ihr aus Post 8 und 12: istioctl proxy-config secret zeigt pro Workload die ausgerollte Kette samt Gültigkeitsdaten, auch für die CA-Zertifikate darüber.

Was passiert, wenn das Datum unbemerkt näher kommt, lässt sich herleiten: Unter einer abgelaufenen Kette gibt es keine gültigen Workload-Zertifikate mehr, und mit STRICT aus Post 14 hängt daran euer gesamter Service-zu-Service-Verkehr.

Für Entscheider ist es ein Datumsvergleich. Ein bekanntes CA-Ablaufdatum ist ein Wartungsfenster, das man Jahre vorher in den Kalender schreibt. Ein unbekanntes ist ein Totalausfall mit Ansage, nur ohne Datum im Kalender.

Hier brennt die Hütte nicht plötzlich. Sie hat einen Zündtimer, und der lief beim Install los.

Genau solche Ablaufdaten fördert ein Assessment zutage, oft als unscheinbarste Zeile mit dem größten Schrecken. Wer sein Datum nicht kennt: Meldet euch gern. Und an alle anderen: Wann habt ihr eure Mesh-CA zuletzt bewusst angesehen?