Authentication is your job
KubeAtlas ships with no built-in authentication. The chart defaults reflect this:
service.type=ClusterIP— the API is not reachable from outside the cluster.ingress.enabled=false— exposing the UI is opt-in.- Flipping
ingress.enabled=trueis rejected by the values schema unless you also setingress.acknowledgeNoBuiltinAuth=true.
This is on purpose. KubeAtlas reads everything in your cluster: namespaces, ConfigMaps, Secrets (metadata, not contents), RBAC. An unauthenticated UI is a cluster-wide read leak.
If you set ingress.enabled=true you must front the Ingress with an
authentication layer. Three options that work today:
oauth2-proxy
Free, widely deployed, sits in front of the Ingress and gates every request through your IdP (Google, GitHub, OIDC, ...).
- Repository: github.com/oauth2-proxy/oauth2-proxy
- Pattern: deploy oauth2-proxy alongside KubeAtlas; configure your
Ingress controller to route
/through oauth2-proxy first (NGINX:auth_request; Traefik:ForwardAuthmiddleware). - Trade-off: one more component to operate.
Pomerium
A reverse proxy with policy-based access control built in. Stronger authorisation story (per-route policies, attribute-based rules) but heavier than oauth2-proxy.
- Site: pomerium.com
- Pattern: route the public hostname for KubeAtlas through Pomerium; Pomerium handles AuthN + AuthZ before forwarding to the in-cluster Service.
- Trade-off: heavier dependency, but the AuthZ model often replaces a separate policy layer.
Cloudflare Access (or equivalent zero-trust gateway)
Auth happens at the edge, before traffic reaches your cluster. Good fit if you already use Cloudflare Tunnel or an equivalent (Tailscale Funnel, Google IAP, AWS Verified Access).
- Site: Cloudflare Access
- Pattern: expose KubeAtlas via a Tunnel; gate the public hostname with an Access policy. The cluster never gets unauthenticated traffic.
- Trade-off: vendor lock-in to the chosen edge provider.
Quick comparison
| Option | Where it runs | Identity | Operational cost |
|---|---|---|---|
| oauth2-proxy | In-cluster, alongside Ingress | OIDC / OAuth2 IdP | Low — one extra Deployment |
| Pomerium | In-cluster, in front of Ingress | OIDC + per-route policy | Medium — replaces some other policy tooling |
| Cloudflare Access | Edge | Cloudflare-managed | Low — but vendor coupling |
There is no fourth, easier option. If you can't pick one of these
or an equivalent zero-trust gateway, leave ingress.enabled=false
and use kubectl port-forward for ad-hoc access.
What KubeAtlas does not do
- Issue or validate tokens.
- Filter API responses based on the caller.
- Audit who looked at what.
Treat KubeAtlas like an internal admin dashboard: anyone who can hit the URL can see every node and edge in the cluster.