Skip to content

OIDC Helm Configuration

OpenDepot ships Dex as a bundled Helm subchart that acts as an OIDC identity broker. Dex federates upstream identity providers such as Entra ID, Okta, GitHub, and LDAP, then issues standard OIDC JWTs. The server validates those JWTs locally through JWKS.

When OIDC is enabled, the server advertises the login.v1 block in its service discovery response. OpenTofu uses that block to authenticate with tofu login without distributing kubeconfig or ServiceAccount credentials.

Note

OIDC and bearer-token modes are mutually exclusive by default. Set server.oidc.enabled: true and server.useBearerToken: false when switching to OIDC.

Configuration Workflow

  •  Core Setup

    Enable Dex and OIDC on the server, apply the Helm upgrade, verify service discovery, and authenticate with tofu login.

  •  Proxy and Deployment Modes

    Configure the recommended server-proxied Dex setup, split-network URLs, or a shared external Dex deployment.

  •  Connectors and Secrets

    Configure upstream IdP connectors, manage client secrets, and review OIDC security requirements.

  •  CI/CD Authentication

    Configure GroupBinding access, ServiceAccount fallback, or Dex client credentials for automated pipelines.

Prerequisites

  • OpenDepot installed through Helm (see Installation)
  • A publicly reachable OpenDepot hostname. HTTPS is required in production.
  • An upstream IdP OAuth application, such as a GitHub App, Azure App Registration, or Okta application

How Authentication Works

Dex acts as a broker between the upstream IdP and OpenDepot. Two independent registrations are involved:

  • A connector tells Dex how to authenticate users against the upstream IdP. Its callback URL points to Dex.
  • A static client registers OpenDepot as an application that receives tokens from Dex. Its redirect URIs are the localhost ports used by tofu login.

See Core Setup for the complete flow and Helm values.