Schluss mit ewigen kubeconfigs: kurzlebige Cluster-Logins mit Pinniped

Der unscheinbarste Dauerläufer im Kubernetes-Alltag ist die kubeconfig-Datei. Sie enthält oft ein langlebiges Token, sie liegt auf dem Laptop, sie wird per Chat geteilt, und sie läuft praktisch nie ab. Pinniped räumt damit auf, indem es den Cluster-Login an den zentralen Identity-Provider hängt und nur kurzlebige Zugänge ausstellt. Das ist mein nächster Baustein in dieser Umgebung, und ich schreibe hier bewusst über das Warum, bevor die Anleitung folgt.

Das Problem mit statischen kubeconfigs

Ein Token, das ein Jahr gültig ist, ist ein Jahr lang ein Risiko. Es lässt sich nicht ansehen, ob es kopiert wurde. Wer das Team verlässt, dessen Zugang bleibt oft bestehen, weil niemand die Datei einsammelt und den Zugang widerruft. Und Rotation, also regelmäßiges Erneuern, passiert in der Praxis fast nie, weil sie Handarbeit ist. Der bequeme Weg und der sichere Weg fallen hier weit auseinander.

Was Pinniped ändert

Mit Pinniped meldet sich der Nutzer per OIDC beim Identity-Provider an, mit demselben Login wie für alles andere. Diese Anmeldung nimmt der Pinniped-Supervisor entgegen, und die Concierge-Komponente im Cluster tauscht sie gegen ein kurzlebiges Cluster-Zertifikat, das nach kurzer Zeit verfällt. Es liegt kein dauerhaftes Secret mehr auf dem Laptop, der Zugang endet mit der Sitzung, und der Entzug läuft zentral: Wer im Identity-Provider deaktiviert wird, kommt auch nicht mehr an den Cluster. Aus „ein Schlüssel für immer“ wird „ein Login für jetzt“.

Warum das zum Rest passt

Wer ohnehin schon einen zentralen Identity-Provider betreibt und darüber die Anwendungen und das GitOps-Werkzeug absichert, bekommt mit Pinniped denselben Login auch für kubectl. Ein Ort für Identitäten, ein Ort zum Entziehen, für Menschen wie für Cluster. Das ist der eigentliche Gewinn: nicht ein weiteres Werkzeug, sondern eine Zugangsart weniger, die aus der Reihe tanzt.

Ehrlich: das ist geplant, nicht erledigt

Pinniped ist in dieser Umgebung mein nächster Schritt, noch nicht ausgerollt. Ich beschreibe hier absichtlich das Konzept und die Motivation, keine fertige Schritt-für-Schritt-Anleitung mit Fallen aus dem Betrieb. Sobald es steht, folgt der Praxisbericht, dann mit den Stolpersteinen, die sich erst beim Ausrollen zeigen. Ich halte es für ehrlicher, das offen zu sagen, als eine Erfahrung vorzugeben, die ich noch nicht gemacht habe.

Sie wollen den Zugang zu Ihren Systemen an echte Identitäten binden, statt an Schlüssel, die nie ablaufen? Ich baue Zugangswege, die zentral steuerbar sind und mit der Sitzung enden. Mehr unter IT-Sicherheit & ISMS, das Erstgespräch ist unverbindlich.