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.

Hosted

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 zwei Einstellungen an deiner Mitgliedschaft. Deine Team-Rolle (Owner, Admin, Member) bestimmt, was du im Dashboard darfst: Owner und Admins verwalten Mitglieder und Rollen, Member nutzen, was ihnen gegeben wurde. Deine Zugriffsstufe (Admin, Editor, Viewer oder keine) wird auf Cluster-Rechte abgebildet: Admins bekommen cluster-admin, Editoren edit, Viewer view auf dem API-Server des Clusters. Das Modell erklärt Zugriff & Rollen.

Die wichtige Konsequenz: Wie du dich anmeldest, ändert nie, was du tun darfst. Berechtigungen kommen aus der Mitgliedschaft, nicht aus der Anmeldemethode. 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. 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:

1. Dein IdP wird bei kubehz ID als externer Provider registriert.
2. Dein Team meldet sich über euer Firmen-Login an (SSO). Konten werden bei der ersten Anmeldung angelegt und verknüpft, genau wie bei GitHub.
3. 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.

Ein Owner oder Admin legt ihn im Dashboard an: Zugriff → Mitglieder → Identitätsanbieter (SSO-Föderation). Eine frische MFA-Prüfung ist erforderlich. Ist die SSO-Föderation für deine Organisation noch nicht aktiviert, sagt das Formular das; dann gilt der Concierge-Weg unten.

Das brauchst du (OIDC-Anbieter):

• Anzeigename: wie der Anbieter auf der Anmeldeseite heißt.
• Issuer-URL: der https-Issuer des Anbieters (sein Discovery-Dokument liegt darunter auf /.well-known/openid-configuration).
• Client-ID und Client-Secret: aus einer Anwendung, die du bei deinem Anbieter für kubehz registrierst.
• Scopes: optional; leer bleiben heißt Standardwerte.

SAML wird im selben Abschnitt unterstützt, falls dein Anbieter kein OIDC spricht.

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 → Zugriff). 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); ein 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.

Nächste Schritte

• Verbinden mit kubectl: mit der gerade eingerichteten Identität eine kubeconfig holen, die kein dauerhaftes Geheimnis enthält.
• Anwendungen (SSO-Gate): dieselbe Anmeldung vor einen Dienst im Cluster setzen, ohne dass der Dienst OIDC unterstützen muss.
• Zugriff & Rollen: Rollen liegen in kubehz; dort entscheidest du, was jede angemeldete Person darf.

---

Doku-Status

Aspekt	Detail
Zustand	Live: Social-Login live; eigener IdP auf Anfrage
Zuletzt geprüft	2026-07-15