Applications (SSO gate)
Put any HTTP service running on your cluster behind kubehz sign-in: at the gateway, with no change to the app. You name the route; kubehz registers the OIDC client, delivers its secret into your cluster and attaches the gateway policy. From then on, visitors hit your service only after signing in.
Hosted
This page describes the hosted feature (dashboard → cluster → the Applications tab); on a self-hosted cluster the same mechanic is the lok8s sso-gate addon with any OIDC issuer you like.
What it does
Your cluster’s gateway (Envoy Gateway) can run a complete OIDC login flow (redirect, callback, session cookie, token validation) in front of a route, before any traffic reaches the service behind it. That means dashboards, admin panels, status pages and internal tools that have no authentication of their own get real sign-in without a sidecar, a proxy container, or a single line of app code.
kubehz automates the tedious half: for every application you protect, the operator registers a dedicated OIDC client at kubehz ID, writes the client secret into your cluster (it never travels through your browser or our API), and attaches the gateway policy to your route.
Requirements
Before a service can be gated, the cluster needs:
- An Envoy Gateway.
envoy-gatewayis a framework add-on that runs in your cluster: pick it in the create wizard’s add-on options. The cluster page’s Add-ons card only shows which framework add-ons are installed; it has no controls. It is not one of the priced hosted add-ons; those are control-plane options. - An
HTTPRoutealready serving the service you want to protect. - A public hostname you control the DNS for, pointing at that gateway.
Protecting a service
- Open the cluster in the dashboard and switch to the Applications tab.
- Protect a service: give it a name, the public hostname, and (if they differ from the defaults) the namespace and
HTTPRoutename. - Watch the state: Pending while the operator converges, then Protected. If your cluster has no Envoy Gateway installed yet, the state reads Gateway missing with a hint. Install the
envoy-gatewayaddon and the gate activates on its own.
Removing an application (behind an explicit confirmation, because it makes the service public again) tears everything down: the policy, the secret, and the OIDC client.
Good to know
- Who can sign in: anyone on your kubehz team. Role-based restrictions (“editors only”) are on the roadmap.
- Which routes qualify: any
HTTPRouteattached to an Envoy Gateway in your cluster. One application per route. - Changing the set requires a fresh second factor (like other security-sensitive actions), and every change lands in your tenant audit log.
- The service itself needs no OIDC support. But if it has native OIDC, prefer wiring that to your identity setup instead of double-gating.
Next steps
- Identity & SSO: if the service speaks OIDC natively, wire it to your identity setup instead of double-gating it behind the application proxy.
- Add-ons: the priced control-plane options (monitoring, logging, backups and the rest).
envoy-gatewayis not one of them; see Requirements for where it comes from. - Connecting with kubectl: reach the same cluster from the command line with the same identity.
Doc status
| Aspect | Detail |
|---|---|
| State | Live: feature live |
| Last reviewed | 15 July 2026 |