Giving Kubernetes ServiceAccounts an identity in Forgejo with oauth2-proxy

Описание и применение

Кодовые агенты, работающие как Kubernetes‑Jobs, теперь аутентифицируются как собственные ServiceAccount, используя токен с аудиторией «forgejo», проверяемый 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

Источник