Access Governance und Audit in Multi-Tenant Umgebungen

Lernziele

Nach dieser Lektion kannst du erklären, warum Access Governance in Multi-Tenant-Umgebungen nicht mit „Cluster-Admin für alle” funktioniert und wie RBAC-Design, Break-Glass, Audit Trails und Access Reviews zusammenspielen. Du kennst ein skalierbares Rollenmodell für Plattform- und Stream-Teams, weißt, wie du Notfallzugriff kontrollierst statt zu verbieten, und kannst Audit-Nachweise aus Kubernetes-API-Logs und Identity-Systemen ableiten. Du kannst den Spannungsbogen zwischen Self-Service und Least Privilege benennen.

Das Problem: Wer hat eigentlich Zugriff — und seit wann?

Montagmorgen, Incident: Ein Pod in Namespace team-checkout löscht Ressourcen in team-payment. Wer war das? Der ServiceAccount? Ein Entwickler mit kubectl? Ein CI-Token? Die kubeconfig von jemandem, der das Unternehmen vor sechs Monaten verlassen hat?

In einer Plattform mit hundert Teams und tausenden Identitäten ist „Zugriff” kein statisches Permission-Set, sondern ein lebendes System: Neue Teams kommen, Projekte enden, Contractor brauchen temporären Zugang, On-Call braucht nachts erweiterte Rechte. Ohne Governance driftet RBAC: Rollen werden nie entzogen, cluster-admin-Bindings häufen sich, und niemand kann im Audit erklären, warum Person X am 14. März Produktion gelöscht hat.

Access Governance ist die Antwort: Wer darf was, warum, wie lange — und wie weisen wir das nach?

RBAC-Design: Rollen statt Einzel-Berechtigungen

Kubernetes RBAC (Roles, ClusterRoles, Bindings) ist mächtig und schnell unübersichtlich. Das Ziel für eine Plattform: wenige, benannte Rollen statt ad-hoc Bindings.

Typisches Rollenmodell:

Rolle	Scope	Rechte
platform-admin	Cluster/Management	Plattform-Komponenten, nicht Team-Workloads
team-developer	Namespace	Deploy, Logs, Port-Forward — kein Secret-Lesezugriff auf fremde NS
team-lead	Namespace	+ Secrets, + RBAC im eigenen NS
viewer	Namespace	Read-only für Observability
ci-deployer	Namespace	Nur Deployments/ConfigMaps — kein kubectl-Interaktiv

Drei Design-Regeln:

Namespace als Mandantengrenze. Stream-Teams bekommen Rechte nur in ihren Namespaces — nie clusterweit, außer explizit begründet. ClusterRoles nur für Plattform-Teams.

Gruppen aus dem IdP mappen. Bindings referenzieren OIDC-Gruppen (team-checkout-developers), nicht einzelne User. Person wechselt Team → Gruppenmitgliedschaft ändert sich → RBAC folgt automatisch.

Kein cluster-admin als Default. Dauerhafte Cluster-Admin-Rechte sind der häufigste Governance-Verstoß. Wer sie braucht, dokumentiert warum — und bekommt sie zeitlich begrenzt (Just-in-Time, siehe unten).

Die Plattform provisioniert RBAC beim Team-Onboarding automatisch: Scaffolder legt Namespace, Quota, NetworkPolicy und RoleBindings an — aus einer zentralen Template-Bibliothek, versioniert in Git.

Break-Glass: Notfallzugriff ohne Wildwest

„Kein Admin-Zugriff” ist keine Option — wenn Produktion brennt, braucht jemand Rechte. Break-Glass ist das kontrollierte Ventil:

1. Separates Break-Glass-Konto oder -Rolle, nicht der Alltags-Account.
2. Aktivierung mit Begründung — Ticket, PagerDuty-Incident, MFA.
3. Zeitlich begrenzt — Session läuft nach 4 Stunden ab; Rechte werden automatisch entzogen.
4. Vollständige Protokollierung — jede Aktion im Audit Log; Post-Incident-Review Pflicht.

Der Trade-off: Break-Glass ist langsamer als kubectl --as=admin. Das ist Absicht. Wer im Interview sagt „im Notfall geben wir temporär cluster-admin”, ohne Protokollierung zu nennen, verliert Punkte.

Alternativen zum breiten Break-Glass: kubectl access mit elevated Role nur für bestimmte Ressourcen (z. B. nur Pods restarten, nicht Secrets lesen) — weniger Risiko, oft ausreichend.

Audit Trails: Nachweis, der nicht lügt

Audit-Nachweise kommen aus zwei Quellen:

Kubernetes Audit Logs — jede API-Anfrage: wer (user.username), was (verb + resource), wann, von welcher IP, Ergebnis. Aktiviert auf der API-Server-Ebene, zentral gesammelt (nicht nur lokal auf dem Master), unveränderlich gespeichert (WORM-Storage oder SIEM mit Retention-Policy).

Identity-System-Logs — wer hat wann welche Gruppe bekommen, wer hat sich authentifiziert, welches Token wurde ausgestellt. Korrelation: Kubernetes-Audit zeigt system:serviceaccount:team-a:deploy; Identity-Log zeigt, welcher Mensch das Token angefordert hat.

Für Multi-Tenant-Plattformen reicht „Logs existieren” nicht — du brauchst Abfragen: „Alle Schreibzugriffe auf Namespace X in den letzten 90 Tagen” muss in Minuten beantwortbar sein, nicht in Tagen manueller Suche.

Access Reviews: Drift stoppen, bevor der Auditor kommt

Technische Controls veralten, wenn niemand prüft, ob sie noch passen. Access Reviews sind der organisatorische Gegenpol zur RBAC-Automatisierung:

• Quartalsweise (oder bei SOC 2/ISO Pflicht): Team-Leads bestätigen, dass ihre Mitglieder noch die richtigen Rechte haben.
• Automatisierte Reports: Liste aller Bindings pro Person; markiere Anomalien (User in mehr als drei Teams, dauerhafte ClusterRole, inaktive Accounts mit Rechten).
• Offboarding-Check: HR-Event → automatisches Entfernen aus IdP-Gruppen → RBAC wirkt innerhalb Minuten, nicht beim nächsten Review.

Die Plattform liefert die Reports; das Security-Team orchestriert den Prozess. Compliance-by-Design (Lektion 43) verlangt beides.

Praxis

Simuliere einen Access-Review-Zyklus:

1. Exportiere alle RoleBindings in einem Test-Cluster: kubectl get rolebindings,clusterrolebindings -A -o yaml.
2. Identifiziere Bindings an einzelne User statt Gruppen — markiere als „zu migrieren”.
3. Finde cluster-admin-Bindings — dokumentiere Begründung oder entferne.
4. Schreibe eine Kyverno/Gatekeeper-Policy: „Kein ClusterRoleBinding an User außerhalb einer Allowlist” (Audit-Mode).
5. Definiere den Break-Glass-Flow als Runbook: Wer aktiviert, wer reviewt danach, wo liegen die Logs.

Optional: Aktiviere Kubernetes Audit Policy auf Metadata-Level minimum für secrets und configmaps — und prüfe, ob die Logs zentral ankommen.

Typische Stolperfallen

RBAC per kubectl ad hoc. Jeder manuelle kubectl create rolebinding ist technische Schuld — nicht versioniert, nicht reviewbar.

ServiceAccount-Token ohne Rotation. Langlebige Tokens in Secrets sind stillschweigende Admin-Backdoors. Bound ServiceAccount Tokens und Workload Identity (Lektion 42).

Audit Logs ohne Retention. Logs, die nach 7 Tagen gelöscht werden, taugen nicht für Compliance.

Access Review als Checkbox. „Alles bestätigt” ohne Anomalie-Report ist Theater.

Break-Glass ohne Post-Review. Notfall-Rechte, die nie entzogen werden, sind Dauer-Admin.

Interview-Vorbereitung

„Wie gestaltest du Access Governance in Multi-Tenant-K8s?” — Problem (RBAC-Drift, undurchsichtige Zugriffe) → Rollenmodell (Namespace-Scoped, IdP-Gruppen) → Break-Glass (zeitlich begrenzt, protokolliert) → Audit + Reviews (Logs + quartalsweise Bestätigung) → Trade-off (Self-Service vs. Least Privilege — Golden Path als Default).

Follow-ups:

• „Wie verhinderst du, dass Teams sich gegenseitig sehen?” — Namespace-Isolation, RBAC, NetworkPolicies — drei Schichten.
• „Was loggst du mindestens?” — API-Audit für Schreibzugriffe, Identity-Events, Break-Glass-Aktivierungen.
• „Wie skalierst du das für 100 Teams?” — Automatisierung beim Onboarding, keine manuellen Bindings.

Zusammenfassung

Access Governance in Multi-Tenant-Umgebungen verlangt ein klares RBAC-Modell mit Namespace-Scoped-Rollen und IdP-Gruppen-Mapping, kontrollierten Break-Glass-Prozessen für Notfälle, zentralen Audit Trails aus Kubernetes- und Identity-Logs sowie regelmäßigen Access Reviews gegen Berechtigungs-Drift. Die Plattform automatisiert RBAC beim Team-Onboarding; menschliche Prozesse fangen an, wo Technik allein nicht reicht. Damit schließt du das Security-&-Compliance-Modul ab — ab Lektion 46 wechseln wir in den Interview-Modus: System Design, Cases und Mock.