feat: external OIDC tokens for self-hosted instances

未關閉
  • 哪裡不對？
#5,090 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
typescript
領域
authentication, backend-api-design

研究方向

Start by tracing getExternalOidcController() and the ExternalOidcPlugin interface, then review the /api/v1/auth/oidc/token route and the existing token claims. Check how the isCloud() gate, OIDC_ISSUER_URL, and run-token setting control minting. Done means self-hosted instances can mint tokens under the stated conditions, the documented claims include the requested identifiers, and tests cover the behavior.

由索引模型根據 Issue 內容生成。

描述

Is your feature request related to a problem? Please describe.

v4.8.3 added auth.getOIDCToken() and @trigger.dev/sdk/oidc/aws, but only Trigger.dev Cloud can mint the tokens. getExternalOidcController() returns null unless isCloud() is true, and the minter is loaded from the closed @triggerdotdev/plugins/oidc module. On a self-hosted instance POST /api/v1/auth/oidc/token returns 503. The open-source repo already has the rest: the OIDC_ISSUER_URL issuer, the /.well-known/jwks.json and discovery routes, the signing key service, run-token verification and the ExternalOidcPlugin interface.

Self-hosted operators are often the ones with the strictest security requirements (FedRAMP, ITAR, HIPAA). A task can only get its credentials from the environment's variables. Every run in an environment receives the same static secrets: database and API admin credentials, cloud keys and vendor tokens. Any task, or any dependency bundled into the image, can read all of them. OIDC would let a task exchange a short-lived token, valid only for one audience, for credentials scoped to that task: AWS roles through STS, token exchange with Keycloak or another IdP, Vault, or GCP and Azure workload identity. The static secrets could then leave the environment.

Describe the solution you'd like to see
  • Enable external OIDC on self-hosted instances when OIDC_ISSUER_URL is set and run tokens are on, with an open-source minter. A self-hosted operator can already provide that minter through the existing plugin interface if only the isCloud() gate is removed.
  • Document the token's claim set. Include run_id, task_id, attempt and deployment_id alongside sub, so a verifier can authorize per task and attribute activity to a run.
  • Optionally, let operators add claims, such as AWS session tags (https://aws.amazon.com/tags). That would let a multi-tenant application drive attribute-based access control from data recorded when the run was triggered.
Describe alternate solutions
  • Workload identity on run pods (IRSA, EKS Pod Identity): the identity belongs to the worker group's service account, so every task in the environment gets the same role. It is AWS-only, and it doesn't identify the run or task.
  • Sending the internal run token (run+jwt) to our own exchange service: its signing keys aren't published, and its audience is trigger:api with admin scope. The receiving service ends up holding a Trigger API credential for the whole environment.
  • Shipping our own @triggerdotdev/plugins/oidc module: the isCloud() check still blocks it.
Additional information

Related: #1851 (OIDC on Cloud runners). I'm happy to help with a PR.

主要語言
TypeScript
星號
16.5k
分支
1.5k
平均合併
1 天 15 小時
30 天內合併 PR
17

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

triggerdotdev/trigger.dev 的其他 Issue

查看 triggerdotdev/trigger.dev 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。