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 (wij koppelen het samen met jou, per organisatie – nog geen owner of admin, in het dashboard; we helpen als federatie voor jullie organisatie nog niet aanstaat): federeer een externe OIDC-provider (Okta, Entra, Google Workspace, …) zodat je team je bestaande bedrijfsidentiteit gebruikt. Zie Aanmelden & je eigen identity provider en Toegang & 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:
- 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.
- De API-server van je gehoste cluster vertrouwt kubehz als zijn OIDC-identiteitsprovider.
- Wanneer je
kubectluitvoert 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.
Zelf gehoste clusters
Alles hierboven beschrijft een gehost cluster. Voor een zelf gehost cluster is het antwoord korter, en het is het belangrijke: de API-server van jouw cluster vertrouwt kubehz niet.
- kubehz is geen identiteitsprovider voor jouw cluster. Je eigen kubeconfig, je eigen RBAC en je eigen gebruikers blijven ongemoeid; inloggen bij kubehz geeft niemand toegang binnen jouw cluster.
- Wat een kubehz-login bepaalt is het dashboard en de API: wie in je team de geregistreerde clusters ziet en wie de teaminstellingen mag wijzigen.
- Het platform maakt nooit verbinding ín een zelf gehost cluster; de agent in het cluster praat alleen naar buiten. Zie Registratie.
Je hebt geen kubehz-account nodig om een cluster te draaien. lo werkt ook zonder.
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
- Toegang & 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 |