Giving Kubernetes ServiceAccounts an identity in Forgejo with oauth2-proxy

说明与用途

作为 Kubernetes Jobs 运行的编码代理现在使用以 "forgejo" 为受众的 ServiceAccount 令牌进行身份验证，该令牌由 oauth2-proxy 验证并通过标头转发给 Forgejo。这样消除了长期令牌、共享身份和值泄漏问题。

问题

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.

结果

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

工作流

• 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.

证据

The credential outlives the work.

来源

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

来源

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

来源

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

来源