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=true is rejected by the values schema unless you also set ingress.acknowledgeNoBuiltinAuth=true.

This is on purpose. KubeAtlas reads broad cluster topology including namespaces, ConfigMaps (including their values), workload specifications, and RBAC. It does not receive permission to list or watch Kubernetes Secrets. Secret nodes are unverified, reference-only placeholders derived from fields in non-Secret objects. An unauthenticated UI is still a cluster-wide information 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: ForwardAuth middleware).
• 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.

Secret boundary

Kubernetes RBAC cannot return Secret metadata without returning the complete Secret object. KubeAtlas therefore does not request get, list, or watch for core/v1 Secrets. A node marked metadata.annotations["kubeatlas.io/reference-only"]="true" means only that another observed resource names that Secret; it does not prove the Secret exists, and it carries no source labels, annotations, type, UID, owner references, or value fields.

Database passwords and optional federation kubeconfigs may still be mounted as specific runtime credentials. KubeAtlas uses those credentials for their configured purpose but must not copy them into the graph, history, rules, diagnostics, exports, logs, or telemetry.