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 (wir richten es gemeinsam mit dir ein, pro Owner oder Admin, im Dashboard; wir helfen, falls die Föderation für eure Organisation noch nicht aktiv ist): föderiere einen externen OIDC-Anbieter (Okta, Entra, Google Workspace, …), sodass dein Team deine bestehende Unternehmensidentität nutzt. Siehe Anmeldung & eigener Identity Provider und Zugriff & 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.
Selbst gehostete Cluster
Alles bisher Beschriebene gilt für einen gehosteten Cluster. Bei einem selbst gehosteten ist die Antwort kürzer, und sie ist die wichtige: der API-Server deines Clusters vertraut kubehz nicht.
- kubehz ist kein Identitätsanbieter für deinen Cluster. Deine kubeconfig, dein RBAC und deine Nutzer bleiben unberührt; eine Anmeldung bei kubehz gewährt niemandem Zugriff in deinem Cluster.
- Eine kubehz-Anmeldung steuert das Dashboard und die API: wer in deinem Team die registrierten Cluster sieht und wer die Team-Einstellungen ändern darf.
- Die Plattform verbindet sich niemals in einen selbst gehosteten Cluster hinein; der Agent im Cluster spricht ausschließlich nach außen. Siehe Registrierung.
Für den Betrieb eines Clusters brauchst du kein kubehz-Konto. lo funktioniert auch ohne.
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
- Zugriff & 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 |