Skip to main content

​
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.
Only oidc gives you per-person attribution in the audit trail; htpasswd shares one identity across everyone with dashboard access.
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. The audit trail also can’t attribute actions to a person in this mode; every action is recorded as unknown.

​
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