Giving Kubernetes ServiceAccounts an identity in Forgejo with oauth2-proxy

Description and use

Coding agents running as Kubernetes Jobs now authenticate as their own ServiceAccount using a token scoped to "forgejo", verified by oauth2-proxy and forwarded to Forgejo via a header. This removes long‑lived tokens, shared identities, and value leakage.

Problem

Each coding agent runs as a Kubernetes Job and needs to authenticate to Forgejo. Using a static Personal Access Token per agent caused long-lived credentials, shared identity, and potential leakage.

Outcome

Agents now authenticate per run with a short‑lived, scoped token that never leaks as a value, eliminating shared identities and long‑lived secrets.

Workflow

• 1. Configure the pod to mount a projected ServiceAccount token with audience "forgejo" and 86400s expiration.
• 2. Ensure the pod entrypoint checks for the token file and exits if missing.
• 3. Wrap the git binary to inject an Authorization header with the token on every call.
• 4. Deploy oauth2-proxy with OIDC settings pointing to the Kubernetes API server, skipping discovery and using the cluster’s JWKS URL.
• 5. Configure Forgejo to enable reverse‑proxy authentication for web UI and API, disabling auto‑registration.
• 6. Agents run, oauth2-proxy verifies the token, forwards the subject as X‑Forwarded‑User, and Forgejo accepts the header as the authenticated user.

Evidence

The credential outlives the work.

Source

It is a shared identity, not a per-run one.

Source

The pod gets one volume. That's the entire credential configuration of an agent

Source

oauth2-proxy normally does "log in with GitHub/Google" for a web app. It also understands bearer tokens

Source