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.

Early access

The hosted control plane is in early access. This page describes the hosted feature (dashboard → cluster → Settings → Applications); 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.

Protecting a service

1. Open the cluster in the dashboard → Settings → Applications.
2. Protect a service: give it a name, the public hostname, and (if they differ from the defaults) the namespace and HTTPRoute name.
3. 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-gateway addon and the gate activates on its own.

Removing an application (behind an explicit confirmation — 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 HTTPRoute attached 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.

---

Doc status

Aspect	Detail
State	early access — feature live
Last reviewed	2026-07-15