Inloggen & je eigen identity provider

kubehz heeft één identiteit voor alles: het account waarmee je het dashboard gebruikt, is dezelfde identiteit die kubectl gebruikt wanneer je verbinding maakt met de standaard OIDC-kubeconfig. Deze pagina legt uit waar die identiteit vandaan komt, hoe rechten worden bepaald en wat "bring your own identity provider" bij kubehz betekent.

Early access

Het gehoste control plane is in early access. Alles op deze pagina geldt voor gehoste clusters; een self-hosted cluster behoudt de authenticatie die je zelf hebt geconfigureerd.

Eén identiteit, één plek voor rechten

Twee losse dingen bepalen wat je mag — en het loont om ze uit elkaar te houden:

• Authenticatie — wie je bent. Geregeld door kubehz ID (onze identiteitsdienst). Je kunt inloggen met e-mail + wachtwoord, een passkey of een gefedereerde provider (zie hieronder).
• Autorisatie — wat je mag. Bepaald door je teamlidmaatschap en rol (owner, admin, editor, viewer). Je rol wordt vertaald naar clusterrechten: admins krijgen cluster-admin, editors edit, viewers view op de API-server van het cluster.

De belangrijke consequentie: hoe je inlogt verandert nooit wat je mag. Rechten komen uit lidmaatschap, niet uit de inlogmethode — en als je een team verlaat, eindigt je clustertoegang daarmee, ongeacht via welke provider je inlogde.

Inloggen via een externe provider

kubehz ID ondersteunt gefedereerd inloggen: in plaats van een kubehz-wachtwoord authenticeer je je bij een externe identity provider en vertrouwt kubehz het resultaat.

• GitHub-inloggen is vandaag beschikbaar voor elk account.
• Bij de eerste gefedereerde login maakt of koppelt kubehz je account automatisch (matching op het geverifieerde e-mailadres), vraagt het om akkoord op de voorwaarden — en vanaf dan lopen je dashboard- én kubectl-sessies via die provider.

Gefedereerde gebruikers zijn volwaardige gebruikers: ze verschijnen in je team, krijgen rollen zoals iedereen en hun OIDC-kubeconfig werkt precies hetzelfde.

Je bedrijfs-IdP koppelen

Draait jouw organisatie een eigen identity provider (Entra ID, Okta, Keycloak, Google Workspace — elke standaard OIDC-IdP), dan kan die aan kubehz ID worden gekoppeld als gefedereerde provider — hetzelfde mechanisme als GitHub-inloggen:

1. Jullie IdP wordt bij kubehz ID geregistreerd als externe provider.
2. Je team logt in via jullie bedrijfslogin (SSO). Accounts worden bij de eerste login aangemaakt en gekoppeld, net als bij GitHub.
3. Lidmaatschap en rollen beheer je in kubehz — wie in het team zit en wat diegene mag — terwijl jullie IdP de authenticatie bezit: jullie wachtwoordbeleid, jullie MFA, jullie offboarding. Schakel iemand uit in jullie IdP en diegene kan niet meer bij kubehz inloggen.

Bedrijfs-IdP-koppelingen zetten we op dit moment samen met jullie, per organisatie op — een selfserviceformulier is er nog niet. Wil je jullie IdP koppelen, neem contact op.

Waarom federatie in plaats van het cluster direct aan jullie IdP hangen?

De API-server van je cluster vertrouwt kubehz ID als token-issuer — met een eigen audience per cluster en groepen die je kubehz-teamrollen coderen. Precies dat maakt lidmaatschapsgedreven toegang mogelijk: voeg in het dashboard een lid toe of verwijder het, en de kubectl-toegang volgt direct, zonder RBAC-objecten die je zelf moet onderhouden. Een cluster dat rechtstreeks aan een externe issuer hangt, verliest precies dat — daarom bieden we een directe "gebruik mijn IdP als API-server-issuer"-modus in de standaardplannen bewust niet aan. Vereist jouw compliance het toch, praat dan met ons over een enterprise-afspraak.

Wat dit in de praktijk betekent

Je wilt	Zo
Inloggen met GitHub	Nu beschikbaar — kies GitHub op de inlogpagina.
Bedrijfs-SSO voor dashboard én kubectl	Koppel jullie IdP aan kubehz ID (contact).
Offboarding via jullie IdP	Werkt: een in jullie IdP uitgeschakelde gebruiker kan geen nieuwe kubehz-sessie starten. Verwijder diegene ook uit het kubehz-team om lopende toegang direct in te trekken.
Clusterrechten beheren via IdP-groepen	Nu nog niet — rollen leven in kubehz (dashboard → Team). IdP-groep-naar-rol-mapping staat op de roadmap voor organisatie-SSO.
Jullie IdP als directe OIDC-issuer van het cluster	Niet in de standaardplannen (zie de tip hierboven) — enterprise-gesprek.

Beveiligingsnotities

• Gevoelige acties (leden wijzigen, tokens aanmaken, admin-kubeconfig downloaden) vereisen een verse tweede factor, ongeacht de inlogmethode.
• De OIDC-kubeconfig bevat nooit een blijvend geheim — zie Verbinden met kubectl.
• Elke inlogmethode komt uit op dezelfde kubehz-identiteit, dus auditgebeurtenissen in het tenant-auditlog noemen altijd dezelfde gebruiker.

---

Documentstatus

Aspect	Detail
Status	early access — functie live
Laatst gecontroleerd	2026-07-15