Wer darf was,
und wer hält den Schlüssel

• Alles verweigert: Ein neues Konto hat genau eine Berechtigte — die Kontoinhaberin. Jede weitere Person und jedes Dienstkonto beginnt ohne Rechte. Es gibt keine Rolle, die beim Anlegen automatisch mitkommt.
• Verweigerung schlägt Erlaubnis: Treffen mehrere Richtlinien auf dieselbe Anfrage zu, gewinnt die Verweigerung — unabhängig von Reihenfolge und Genauigkeit der Regel.
• Keine Vererbung über Projektgrenzen: Rechte in einem Projekt sagen nichts über ein anderes. Wer projektübergreifend arbeiten muss, braucht eine Rolle je Projekt oder eine Rolle auf Kontoebene.
• Zwei Faktoren für schreibende Rollen: Administrator, Betreiber und Sicherheitsbeauftragte lassen sich nur an Personen vergeben, die einen zweiten Faktor hinterlegt haben. Zugelassen sind TOTP (Einmalcodes aus einer Authentifizierungs-App) und WebAuthn (Sicherheitsschlüssel oder Gerätebiometrie); Wiederherstellungscodes gibt es einmalig beim Anlegen.
• Dienstkonten ohne Verfallsdatum gibt es nicht: Ein Zugriffstoken lebt eine Stunde, ein Schlüsselpaar höchstens 90 Tage. Ab Tag 60 erscheint eine Warnung im Konto und in der API-Antwort als Kopfzeile.
• Der Prüfpfad ist nicht abschaltbar: Auch die Kontoinhaberin kann ihn nicht ausschalten, nicht kürzen und keine Einträge löschen. Das ist Absicht und die Bedingung dafür, dass er als Nachweis taugt.

Ein Dienstkonto gehört zu einem Projekt, nicht zu einer Person. Es kann Rollen tragen, aber keine Rollen vergeben, und es hat keinen Zugang zur Weboberfläche.

Für Systeme innerhalb der Plattform ist der bessere Weg der Verbund über das projizierte Token des Clusters — einen kurzlebigen Ausweis, den Kubernetes dem Pod selbst ausstellt. Dann liegt überhaupt kein dauerhaftes Zugangsdatum herum, das jemand kopieren könnte.