Skip to main content

Enable OIDC for FleetForge

Switching from static demo tokens to OIDC provides revocable, auditable access for every user. This guide wires OIDC into the runtime and UI.

Prerequisites​

  • Identity provider that supports OIDC (Auth0, Okta, Google Workspace, etc.).
  • Client ID/secret and issuer URL for the FleetForge application.
  • Role claims or groups that map to FleetForge reader / writer privileges.

1. Configure the runtime​

Set the following environment variables (Helm values, Cloud Run env vars, or local shell) before starting fleetforge-runtime:

  • FLEETFORGE_OIDC_ISSUER=https://<your-issuer>
  • FLEETFORGE_OIDC_AUDIENCE=<runtime-audience>
  • FLEETFORGE_OIDC_ROLE_MAP=reader:group:ff-readers,writer:group:ff-writers

The runtime verifies bearer tokens on every request and enforces roles based on the map you provide. Remove demo tokens (FLEETFORGE_API_TOKENS) once OIDC is in place.

2. Update the UI​

Configure the Next.js console to obtain tokens from the same provider:

NEXT_PUBLIC_OIDC_ISSUER=https://<your-issuer>
NEXT_PUBLIC_OIDC_CLIENT_ID=<console-client-id>
NEXT_PUBLIC_OIDC_AUDIENCE=<runtime-audience>

Store secrets in your deployment platform (Vercel, Cloud Run, Kubernetes Secret). The UI requests reader tokens by default; writers can eject to the CLI or use scoped PATs.

3. Test the flow​

  1. Log out of any previous session.
  2. Start the UI and runtime with the new env vars.
  3. Sign in through the OIDC provider; confirm the Runs Explorer loads and actions match the assigned role.
  4. Attempt a forbidden action (for example, submit a run as a reader) to ensure RBAC denies the request.

4. Rotate secrets and audit​

  • Rotate client secrets on a regular cadence (quarterly at minimum).
  • Record the change in ChangeOps with a link to the OIDC configuration diff.
  • Export audit logs (fleetforge-ctl audit export) to capture authentication events alongside runtime activity.