Identität & Anmeldung
Alles, was du mit kubehz tust — das Dashboard, die API und kubectl auf einem gehosteten Cluster — liegt hinter einer einzigen Anmeldung. Diese Seite erklärt, wie diese Anmeldung funktioniert und wie sie deine Cluster erreicht.
Ein Identitätsanbieter
kubehz betreibt seinen eigenen Single-Sign-On-Identitätsanbieter (auf Basis von ZITADEL). Du meldest dich einmal bei kubehz an, und diese Identität wird überall verwendet. Es gibt kein separates Cluster-Passwort zu verwalten.
Du kannst dich anmelden mit:
- E-Mail und Passwort, geschützt durch Zwei-Faktor-Authentifizierung;
- GitHub;
- Google;
- deinem eigenen SSO — föderiere einen externen OIDC-Anbieter (Okta, Entra, Google Workspace, …), sodass dein Team deine bestehende Unternehmensidentität nutzt. Siehe Team & Rollen.
Dein Team ist isoliert
Jedes Team erhält seine eigene Identitätsorganisation. Deine Mitglieder, ihre Rollen und jedes SSO, das du föderierst, leben innerhalb deiner Organisation und nirgendwo sonst — ein Team kann niemals die Personen oder den Zugriff eines anderen Teams sehen oder beeinflussen. Diese Isolation ist die Grundlage dafür, wie der Cluster-Zugriff zwischen Kunden getrennt bleibt.
Wie aus der Anmeldung Cluster-Zugriff wird
Für einen gehosteten Cluster verwaltest du nie einen separaten Satz von Kubernetes-Benutzern. Es funktioniert so:
- Du meldest dich bei kubehz an. Deine Stufe und benutzerdefinierten Rollen werden deinem Token als Gruppen-Claims angehängt, gekennzeichnet mit der Organisation deines Teams.
- Der API-Server deines gehosteten Clusters vertraut kubehz als seinem OIDC-Identitätsanbieter.
- Wenn du
kubectlmit der OIDC-kubeconfig ausführst, liest der API-Server diese Gruppen und bildet sie auf Kubernetes-RBAC ab — aber nur die Bindungen für die Organisation deines Teams passen, sodass ein Token eines Teams niemals Zugriff auf den Cluster eines anderen Teams erlangen kann.
Das Ergebnis: Füge jemanden mit einer Rolle zu deinem Team hinzu, und die Person kann kubectl sofort nutzen; entferne sie, und ihr Zugriff endet — keine Cluster-seitige Benutzerverwaltung und keine Möglichkeit, dass Zugriff zwischen Teams überspringt.
Step-up für sensible Aktionen
Aktionen, die Zugriff gewähren oder erweitern — ein Mitglied einladen, die langlebige Admin-kubeconfig aktivieren — fordern eine frische Zwei-Faktor-Anmeldung genau in dem Moment, in dem du sie ausführst, selbst wenn du bereits angemeldet bist. Das verhindert, dass eine gestohlene oder vergessene Sitzung ausreicht, um Zugriff zu vergeben.
Nächste Schritte
- Team & Rollen — Stufen, benutzerdefinierte Rollen und SSO.
- Verbinden mit kubectl — die OIDC-kubeconfig in der Praxis.
- Wie es funktioniert — das Hosting-×-Access-Modell und die Vertrauensgrenze.
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | aktiv |
| Zuletzt geprüft | 2026-07-14 |