Anmeldung & dein eigener Identity Provider
kubehz hat eine Identität für alles: Das Konto, mit dem du das Dashboard nutzt, ist dieselbe Identität, die kubectl verwendet, wenn du dich mit der standardmäßigen OIDC-kubeconfig verbindest. Diese Seite erklärt, woher diese Identität kommt, wie Berechtigungen entschieden werden und was „bring your own Identity Provider" bei kubehz bedeutet.
Early Access
Die gehostete Control Plane ist im Early Access. Alles auf dieser Seite gilt für gehostete Cluster; ein selbst gehosteter Cluster behält die Authentifizierung, die du selbst konfiguriert hast.
Eine Identität, ein Ort für Berechtigungen
Zwei getrennte Dinge entscheiden, was du tun darfst — und es lohnt sich, sie auseinanderzuhalten:
- Authentifizierung — wer du bist. Übernimmt kubehz ID (unser Identitätsdienst). Du kannst dich mit E-Mail + Passwort, einem Passkey oder einem föderierten Provider anmelden (siehe unten).
- Autorisierung — was du darfst. Entscheiden deine Team-Mitgliedschaft und Rolle (Owner, Admin, Editor, Viewer). Deine Rolle wird auf Cluster-Rechte abgebildet: Admins bekommen
cluster-admin, Editorenedit, Viewerviewauf dem API-Server des Clusters.
Die wichtige Konsequenz: Wie du dich anmeldest, ändert nie, was du tun darfst. Berechtigungen kommen aus der Mitgliedschaft, nicht aus der Anmeldemethode — und wenn du ein Team verlässt, endet dein Cluster-Zugriff damit, egal über welchen Provider du dich angemeldet hast.
Anmeldung über einen externen Provider
kubehz ID unterstützt föderierte Anmeldung: Statt eines kubehz-Passworts authentifizierst du dich bei einem externen Identity Provider, und kubehz vertraut dem Ergebnis.
- GitHub-Anmeldung ist heute für jedes Konto verfügbar.
- Bei der ersten föderierten Anmeldung legt kubehz dein Konto automatisch an oder verknüpft es (Abgleich über die verifizierte E-Mail-Adresse), fragt die AGB-Zustimmung ab — und ab dann laufen Dashboard- und
kubectl-Sitzungen über diesen Provider.
Föderierte Nutzer sind vollwertige Nutzer: Sie erscheinen in deinem Team, bekommen Rollen wie alle anderen, und ihre OIDC-kubeconfig funktioniert genauso.
Deinen Firmen-IdP anbinden
Wenn deine Organisation einen eigenen Identity Provider betreibt (Entra ID, Okta, Keycloak, Google Workspace — jeder standardkonforme OIDC-IdP), kann er als föderierter Provider an kubehz ID angebunden werden — derselbe Mechanismus wie bei der GitHub-Anmeldung:
- Dein IdP wird bei kubehz ID als externer Provider registriert.
- Dein Team meldet sich über euer Firmen-Login an (SSO). Konten werden bei der ersten Anmeldung angelegt und verknüpft, genau wie bei GitHub.
- Mitgliedschaft und Rollen verwaltest du in kubehz — wer im Team ist und was die Person darf —, während dein IdP die Authentifizierung besitzt: eure Passwort-Richtlinien, eure MFA, euer Offboarding. Deaktivierst du jemanden in eurem IdP, kann er sich nicht mehr bei kubehz anmelden.
Firmen-IdP-Anbindungen richten wir derzeit pro Organisation gemeinsam mit euch ein — ein Self-Service-Formular gibt es noch nicht. Wenn du deinen IdP anbinden möchtest, melde dich bei uns.
Warum Föderation statt „Cluster direkt an den IdP"?
Der API-Server deines Clusters vertraut kubehz ID als Token-Aussteller — mit einer eigenen Audience pro Cluster und Gruppen, die deine kubehz-Team-Rollen kodieren. Genau das macht den mitgliedschaftsgesteuerten Zugriff möglich: Füge im Dashboard ein Mitglied hinzu oder entferne es, und der kubectl-Zugriff folgt sofort — ohne dass du RBAC-Objekte pflegen musst. Ein Cluster, der direkt an einen externen Aussteller angebunden ist, verlöre genau das — deshalb bieten wir einen direkten „nimm meinen IdP als API-Server-Issuer"-Modus in den Standard-Tarifen bewusst nicht an. Wenn deine Compliance das erfordert, sprich mit uns über eine Enterprise-Vereinbarung.
Was das praktisch bedeutet
| Du möchtest | So geht's |
|---|---|
| Anmeldung mit GitHub | Sofort verfügbar — wähle GitHub auf der Anmeldeseite. |
Firmen-SSO für Dashboard und kubectl | IdP an kubehz ID anbinden (melde dich). |
| Offboarding über euren IdP | Funktioniert: Ein im IdP deaktivierter Nutzer kann keine neue kubehz-Sitzung starten. Entferne ihn zusätzlich aus dem kubehz-Team, um laufenden Zugriff sofort zu entziehen. |
| Cluster-Rechte über IdP-Gruppen verwalten | Heute nicht — Rollen leben in kubehz (Dashboard → Team). IdP-Gruppen-zu-Rollen-Mapping steht für Organisations-SSO auf der Roadmap. |
| Euer IdP als direkter OIDC-Issuer des Clusters | Nicht in den Standard-Tarifen (siehe Hinweis oben) — Enterprise-Gespräch. |
Sicherheitshinweise
- Sensible Aktionen (Mitglieder ändern, Tokens ausstellen, Admin-kubeconfig herunterladen) erfordern einen frischen zweiten Faktor — unabhängig von der Anmeldemethode.
- Die OIDC-kubeconfig enthält nie ein dauerhaftes Geheimnis — siehe Verbinden mit kubectl.
- Jede Anmeldemethode mündet in derselben kubehz-Identität, Audit-Ereignisse im Tenant-Audit-Log nennen also immer denselben Nutzer.
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | Early Access — Funktion live |
| Zuletzt geprüft | 2026-07-15 |