Sign-in & Your Own Identity Provider
kubehz has one identity for everything: the account you use for the dashboard is the same identity kubectl uses when you connect with the default OIDC kubeconfig. This page explains where that identity comes from, how permissions are decided, and what "bring your own identity provider" means on kubehz.
Early access
The hosted control plane is in early access. Everything on this page applies to hosted clusters; a self-hosted cluster keeps whatever authentication you configured yourself.
One identity, one place for permissions
Two separate things decide what you can do, and it pays to keep them apart:
- Authentication — who you are. Handled by kubehz ID (our identity service). You can sign in with an email + password, a passkey, or a federated provider (see below).
- Authorization — what you may do. Decided by your team membership and role (owner, admin, editor, viewer). Your role maps to cluster permissions: admins get
cluster-admin, editors getedit, viewers getviewon the cluster's API server.
The important consequence: how you sign in never changes what you're allowed to do. Permissions come from membership, not from the login method — and when you leave a team, your cluster access ends with it, no matter which provider you signed in through.
Signing in with an external provider
kubehz ID supports federated sign-in: instead of a kubehz password, you authenticate with an external identity provider and kubehz trusts the result.
- GitHub sign-in is available today on every account.
- On first federated sign-in, kubehz creates or links your account automatically (matching on the verified email address), asks for Terms acceptance, and from then on your dashboard and
kubectlsessions ride that provider.
Federated users are full users: they appear in your team, get roles like everyone else, and their OIDC kubeconfig works exactly the same way.
Bringing your company IdP
If your organization runs its own identity provider (Entra ID, Okta, Keycloak, Google Workspace, any standard OIDC IdP), it can be connected to kubehz ID as a federated provider — the same mechanism GitHub sign-in uses:
- Your IdP is registered with kubehz ID as an external provider.
- Your team signs in through your company login (SSO). Accounts are created and linked on first sign-in, just like GitHub.
- You manage membership and roles in kubehz — who is on the team and what they may do — while your IdP owns the authentication: your password policies, your MFA, your offboarding. Disable someone in your IdP and they can no longer sign in to kubehz.
Company IdP connections are currently set up by us, per organization — there is no self-service form yet. If you want your IdP connected, contact us and we'll wire it up together.
Why federation instead of pointing the cluster at your IdP?
Your cluster's API server trusts kubehz ID as its token issuer — with a dedicated audience per cluster and groups that encode your kubehz team roles. That's what makes membership-driven access work: add or remove a member in the dashboard and their kubectl access follows immediately, with no RBAC objects for you to maintain. A cluster wired directly to an external issuer would lose exactly that — so a direct "use my IdP as the API server issuer" mode is deliberately not offered on the standard plans. If your compliance setup requires it, talk to us about an enterprise arrangement.
What this means in practice
| You want | How |
|---|---|
| Sign in with GitHub | Available now — pick GitHub on the sign-in page. |
Company SSO for the dashboard and kubectl | Connect your IdP to kubehz ID (contact us). |
| Offboarding via your IdP | Works: a user disabled in your IdP can't start a new kubehz session. Also remove them from the kubehz team to revoke running access immediately. |
| Manage cluster permissions in your IdP's groups | Not today — roles live in kubehz (dashboard → Team). IdP-group-to-role mapping is on the roadmap for organization SSO. |
| Your IdP as the cluster's direct OIDC issuer | Not on standard plans (see the note above) — enterprise conversation. |
Security notes
- Sensitive actions (member changes, token minting, admin kubeconfig download) require a fresh second factor regardless of sign-in method.
- The OIDC kubeconfig never contains a durable secret — see Connecting with kubectl.
- Every sign-in method ends up as the same kubehz identity, so audit events in the tenant audit log always name the same user.
Doc status
| Aspect | Detail |
|---|---|
| State | early access — feature live |
| Last reviewed | 2026-07-15 |