Overview
The Thoras dashboard ships with authentication enabled by default. Requests hit
an oauth2-proxy sidecar in the
dashboard pod. Only authenticated requests reach the dashboard container.
Two modes are supported, selected via thorasDashboard.auth.mode:
htpasswd (default): a username and password generated in-cluster on
first install by the Thoras config-controller. No external setup is required.oidc: OIDC login against your identity provider (Okta, Azure Entra ID,
or any OIDC-compliant provider). You provide the client credentials in a
Secret you manage.
Fields under the unused mode’s block are ignored, so you can switch modes by
changing auth.mode.
Credentials and session cookies are only meaningful behind TLS. Terminate TLS
at your ingress before exposing the dashboard beyond kubectl port-forward,
and set thorasDashboard.auth.cookieSecure: true. The chart default is
false so that port-forward works over plain HTTP. This default is suitable
for evaluation only. Safari drops Secure cookies over plain HTTP, so you
cannot enable cookieSecure and use kubectl port-forward together from a
Mac.
Pick a mode
Other OIDC-compliant providers work with provider: oidc. The Okta and Entra
guides show the general shape.
Migrating from a hand-rolled oauth2-proxy sidecar
Before chart 5.0, the documented way to protect the dashboard was to add your
own oauth2-proxy container under thorasDashboard.extraContainers and retarget
the Service at port 4180. The chart now ships that sidecar for you. Migrating
keeps your IdP app registration and your existing oauth2-proxy-secrets Secret.
Only values.yaml changes.
Remove the old wiring, noting the values of your existing oauth2-proxy flags
for the next step:
Add the built-in sidecar configuration, substituting the values you noted:
The chart reads client-id, client-secret, and cookie-secret from the
existing Secret by default (key names are configurable under
auth.oidc.existingSecret). The Service goes back to targeting the dashboard’s
containerPort, now owned by the chart’s sidecar, so no service.targetPort
override is needed.
Bring your own auth
Set thorasDashboard.auth.enabled: false if you already gate the dashboard
somewhere else, such as an auth plugin at the ingress or gateway, a service-mesh
policy, or a custom SSO sidecar wired through thorasDashboard.extraContainers
and thorasDashboard.service.targetPort.
With built-in auth disabled, the dashboard’s nginx listens on
thorasDashboard.containerPort with nothing in front of it. Any workload in
the cluster that can reach the thoras-dashboard Service can then use part of
the Thoras API without authentication, bypassing the shared apiClientSecret.
Only disable built-in auth if something external gates every request.
NetworkPolicy and OIDC
If you enable the chart’s
NetworkPolicy alongside OIDC mode,
the chart opens egress on port 443 from the dashboard pod so the sidecar can
reach your identity provider. Tighten this with a layered policy scoped to your
IdP’s hostnames (for example a CiliumNetworkPolicy with toFQDNs) if your
security posture requires it.
Further reading
