Team & roles
From the dashboard's Team area you invite people to your team and decide what each of them can do — both in the dashboard and, for hosted clusters, inside Kubernetes itself. Access is granted two ways that combine: a tier everyone has, plus optional custom roles.
Inviting members
Invite a member by email. They receive an invitation and sign in with kubehz (email + password with two-factor, GitHub, or your own SSO — see Identity & sign-in). Adding or changing a member is a sensitive action and asks you to confirm with a fresh two-factor sign-in.
Only a team owner or admin can manage members and roles.
The three access tiers
Every member has exactly one tier. On a hosted cluster the tier maps directly to built-in Kubernetes access:
| Tier | In the cluster | Kubernetes role |
|---|---|---|
| Admin | Full control, including secrets and RBAC. | cluster-admin |
| Editor | Read and write most resources; no roles or cluster-level settings. | edit |
| Viewer | Read-only, without secrets. | view |
The tier is the baseline. For most teams the three tiers are all you need.
Custom roles
When a tier is too broad, define a custom role: narrower, safer access you compose in a permissions matrix — rows are Kubernetes resources (pods, logs, deployments, your CRDs, …), columns are actions (get, list, watch, create, update, delete, …); tick exactly what the role may do. A custom role is granted in addition to a member's tier — it only ever adds access, never reduces it.
Templates. You don't have to start from an empty grid. The editor ships reviewed starting points — Log Viewer, Debugger, Deployment Manager and Cluster Observer — that prefill the matrix; adjust the ticks and save. The saved role is always the matrix itself, so what you see is exactly what the cluster enforces.
Your own resources. The matrix lists the standard Kubernetes resources plus everything your hosted clusters actually serve — including CRDs — with a badge showing which clusters serve each resource. Clusters can differ: a rule naming a resource some cluster doesn't have is perfectly fine and simply has no effect there until the CRD appears.
Sensitive actions (reading secrets, exec into pods, impersonation, RBAC escalation) are flagged in the editor so an over-broad role is visible before you save it.
Scope. A role applies to the whole cluster by default, or you can restrict it to named namespaces (for example, give a contractor Debugger only in staging).
Assigning. Create roles in the Team area's Roles section, then tick them on a member (or on the invite form). Defining a role grants nothing on its own; assigning it does.
Choosing clusters per member
Both the tier and each custom-role assignment can be limited to selected hosted clusters. By default a member's access applies to all of your team's hosted clusters; pick specific clusters when someone should only touch some of them — for example, an external developer who is Editor on the staging cluster only, plus Log Viewer on production.
Cluster scoping applies to hosted clusters (where kubehz manages the cluster's access). Self-hosted clusters keep whatever access you configure yourself.
Bring your own SSO
You can federate your own external OIDC identity provider (Okta, Entra, Google Workspace, or any OIDC provider) so your team signs in with your existing corporate identity. kubehz brokers the login and issues the same access — your tier and roles still decide what each person can do. See Identity & sign-in.
How it reaches the cluster
Your tier and custom roles become group claims in the token kubehz issues when you sign in. A hosted cluster's API server trusts kubehz as its identity provider and maps those groups to Kubernetes RBAC — scoped to your team so one team's access can never apply to another's cluster. You connect with the OIDC kubeconfig; the cluster enforces exactly your role.
Next steps
- Connecting with kubectl — download and use the OIDC kubeconfig.
- Identity & sign-in — sign-in options and per-team isolation.
- Dashboard — the rest of what the dashboard gives you.
Doc status
| Aspect | Detail |
|---|---|
| State | active |
| Last reviewed | 2026-07-16 |