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.

Hosted

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 two settings on your membership. Your team role (owner, admin, member) says what you may do in the dashboard: owners and admins manage members and roles, members use what they were given. Your access tier (admin, editor, viewer, or none) maps to cluster permissions: admins get cluster-admin, editors get edit, viewers get view on the cluster’s API server. See Access & roles for the model.

The important consequence: how you sign in never changes what you’re allowed to do. Permissions come from membership, not from the login method. 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 kubectl sessions 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:

1. Your IdP is registered with kubehz ID as an external provider.
2. Your team signs in through your company login (SSO). Accounts are created and linked on first sign-in, just like GitHub.
3. 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.

An owner or admin adds one in the dashboard: Access → Members → Identity Provider (SSO federation). A recent MFA check is required. If SSO federation is not enabled for your organization yet, the form says so; that is when the concierge path below applies.

Have these ready (an OIDC provider):

• Display name: what the provider is called on the sign-in screen.
• Issuer URL: the provider’s https issuer (its discovery document lives at /.well-known/openid-configuration under that issuer).
• Client ID and Client secret: from an application you register with your provider for kubehz.
• Scopes: optional; the defaults are used when you leave this empty.

SAML is supported through the same section if your provider does not speak OIDC.

Want your company IdP connected?

Connect your company IdP

We set it up with you, usually within one business day.

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 → Access). 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); an 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.

Next steps

• Connecting with kubectl: use the identity you just set up to get a kubeconfig that carries no durable secret.
• Applications (SSO gate): put the same sign-in in front of a service running in your cluster, without the service supporting OIDC.
• Access & roles: roles live in kubehz, so this is where you decide what each signed-in person may do.

---

Doc status

Aspect	Detail
State	Live: social sign-in live; bring-your-own IdP on request
Last reviewed	15 July 2026