Identiteit & aanmelden

Alles wat je met kubehz doet — het dashboard, de API en kubectl op een gehost cluster — zit achter één aanmelding. Deze pagina legt uit hoe die login werkt en hoe hij je clusters bereikt.

Eén identiteitsprovider

kubehz draait zijn eigen single sign-on-identiteitsprovider (gebouwd op ZITADEL). Je meldt je één keer aan bij kubehz en die identiteit wordt overal gebruikt. Er is geen apart clusterwachtwoord om te beheren.

Je kunt je aanmelden met:

• E-mail en wachtwoord, beschermd met tweefactorauthenticatie;
• GitHub;
• Google;
• je eigen SSO — federeer een externe OIDC-provider (Okta, Entra, Google Workspace, …) zodat je team je bestaande bedrijfsidentiteit gebruikt. Zie Team & rollen.

Je team is geïsoleerd

Elk team krijgt zijn eigen identiteitsorganisatie. Je leden, hun rollen en elke SSO die je federeert leven binnen je organisatie en nergens anders — het ene team kan nooit de mensen of toegang van een ander team zien of beïnvloeden. Deze isolatie is het fundament van hoe clustertoegang gescheiden blijft tussen klanten.

Hoe aanmelden clustertoegang wordt

Voor een gehost cluster beheer je nooit een aparte set Kubernetes-gebruikers. Het werkt zo:

1. Je meldt je aan bij kubehz. Je tier en aangepaste rollen worden als group claims aan je token gehecht, getagd met de organisatie van je team.
2. De API-server van je gehoste cluster vertrouwt kubehz als zijn OIDC-identiteitsprovider.
3. Wanneer je kubectl uitvoert met de OIDC-kubeconfig, leest de API-server die groepen en verwijst ze naar Kubernetes-RBAC — maar alleen de bindings voor de organisatie van jouw team matchen, zodat een token van het ene team nooit toegang kan krijgen op het cluster van een ander team.

Het resultaat: voeg iemand met een rol toe aan je team en ze kunnen meteen kubectl gebruiken; verwijder ze en hun toegang eindigt — geen gebruikersbeheer aan de clusterkant, en geen manier voor toegang om over te steken tussen teams.

Step-up voor gevoelige acties

Acties die toegang verlenen of verbreden — een lid uitnodigen, de langlevende admin-kubeconfig inschakelen — vragen op het moment dat je ze uitvoert om een verse tweefactor-aanmelding, zelfs als je al bent ingelogd. Dit voorkomt dat een gestolen of vergeten sessie volstaat om toegang uit te delen.

Volgende stappen

• Team & rollen — tiers, aangepaste rollen en SSO.
• Verbinden met kubectl — de OIDC-kubeconfig in de praktijk.
• Hoe het werkt — het hosting × access-model en de vertrouwensgrens.

---

Documentstatus

Aspect	Detail
Status	actief
Laatst gecontroleerd	2026-07-14