Team & rollen
Vanuit het Team-gedeelte van het dashboard nodig je mensen uit voor je team en bepaal je wat ieder van hen mag doen — zowel in het dashboard als, voor gehoste clusters, binnen Kubernetes zelf. Toegang wordt op twee manieren verleend die samenkomen: een tier die iedereen heeft, plus optionele aangepaste rollen.
Leden uitnodigen
Nodig een lid uit via e-mail. Ze ontvangen een uitnodiging en melden zich aan met kubehz (e-mail + wachtwoord met tweefactor, GitHub, of je eigen SSO — zie Identiteit & aanmelden). Een lid toevoegen of wijzigen is een gevoelige actie en vraagt je om te bevestigen met een verse tweefactor-aanmelding.
Alleen een team-owner of admin kan leden en rollen beheren.
De drie toegangstiers
Elk lid heeft precies één tier. Op een gehost cluster verwijst de tier direct naar ingebouwde Kubernetes-toegang:
| Tier | In het cluster | Kubernetes-rol |
|---|---|---|
| Admin | Volledige controle, inclusief secrets en RBAC. | cluster-admin |
| Editor | Lees en schrijf de meeste resources; geen rollen of instellingen op clusterniveau. | edit |
| Viewer | Alleen-lezen, zonder secrets. | view |
De tier is de basislijn. Voor de meeste teams zijn de drie tiers alles wat je nodig hebt.
Aangepaste rollen
Wanneer een tier te breed is, definieer je een aangepaste rol: smallere, veiligere toegang die je samenstelt in een permissiematrix — rijen zijn Kubernetes-resources (pods, logs, deployments, je CRD's, …), kolommen zijn acties (get, list, watch, create, update, delete, …); vink precies aan wat de rol mag. Een aangepaste rol wordt bovenop de tier van een lid verleend — hij voegt alleen ooit toegang toe, vermindert die nooit.
Sjablonen. Je hoeft niet met een leeg raster te beginnen. De editor bevat beoordeelde startpunten — Log Viewer, Debugger, Deployment Manager en Cluster Observer — die de matrix vooraf invullen; pas de vinkjes aan en sla op. De opgeslagen rol is altijd de matrix zelf, dus wat je ziet is precies wat het cluster afdwingt.
Je eigen resources. De matrix toont de standaard Kubernetes-resources plus alles wat je gehoste clusters daadwerkelijk serveren — inclusief CRD's — met een badge die laat zien welke clusters elke resource kennen. Clusters mogen verschillen: een regel die een resource noemt die een cluster niet heeft, is prima en heeft daar simpelweg geen effect totdat de CRD verschijnt.
Gevoelige acties (secrets lezen, exec in pods, impersonatie, RBAC-escalatie) worden in de editor gemarkeerd, zodat een te brede rol zichtbaar is voordat je hem opslaat.
Scope. Een rol geldt standaard voor het hele cluster, of je kunt hem beperken tot benoemde namespaces (geef een externe medewerker bijvoorbeeld Debugger alleen in staging).
Toewijzen. Maak rollen aan in het Rollen-gedeelte van het Team-gebied en vink ze vervolgens aan bij een lid (of op het uitnodigingsformulier). Het definiëren van een rol verleent op zichzelf niets; het toewijzen ervan wel.
Clusters per lid kiezen
Zowel de tier als elke toewijzing van een aangepaste rol kan worden beperkt tot geselecteerde gehoste clusters. Standaard geldt de toegang van een lid voor alle gehoste clusters van je team; kies specifieke clusters wanneer iemand er maar een paar mag aanraken — bijvoorbeeld een externe ontwikkelaar die alleen op het staging-cluster Editor is, plus Log Viewer op productie.
Clusterbeperking geldt voor gehoste clusters (waar kubehz de toegang beheert). Self-hosted clusters behouden de toegang die je zelf configureert.
Breng je eigen SSO mee
Je kunt je eigen externe OIDC-identiteitsprovider federeren (Okta, Entra, Google Workspace, of een willekeurige OIDC-provider) zodat je team zich aanmeldt met je bestaande bedrijfsidentiteit. kubehz bemiddelt de login en verleent dezelfde toegang — je tier en rollen bepalen nog steeds wat ieder mag doen. Zie Identiteit & aanmelden.
Hoe het het cluster bereikt
Je tier en aangepaste rollen worden group claims in de token die kubehz uitgeeft wanneer je je aanmeldt. De API-server van een gehost cluster vertrouwt kubehz als zijn identiteitsprovider en verwijst die groepen naar Kubernetes-RBAC — beperkt tot je team, zodat de toegang van het ene team nooit kan gelden voor het cluster van een ander. Je maakt verbinding met de OIDC-kubeconfig; het cluster handhaaft precies je rol.
Volgende stappen
- Verbinden met kubectl — download en gebruik de OIDC-kubeconfig.
- Identiteit & aanmelden — aanmeldopties en isolatie per team.
- Dashboard — de rest van wat het dashboard je biedt.
Documentstatus
| Aspect | Detail |
|---|---|
| Status | actief |
| Laatst gecontroleerd | 2026-07-16 |