platform: a machine identity that can create projects and issue their deploy tokens
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 28/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- github, typescript
- 領域
- api, authentication
調査の方向性
Start with the access rules in platform/packages/api/src/middleware/platform-access.ts, then read project creation in platform/packages/api/src/routes/projects.ts and credential issuance in platform/packages/api/src/routes/project-tokens.ts. The issue asks the maintainers to agree on the identity model and ownership rules before implementation. Done means a supported approach is agreed; no implementation scope or acceptance criteria are provided yet.
索引モデルが issue の本文から書いたものです。
説明
Motivation
We run a self-hosted Void platform behind Cloudflare Access for LumiOS, an internal agent platform (the connected-app client from #631). LumiOS agents build small web apps for our users. Each app needs its own D1, KV, R2, queues and Durable State, and Void scopes those to a project, so LumiOS needs to create one project per app and deploy to it, unattended, from a server.
Deploying works today: a project credential (aud: deploy) plus our Access service token is admitted for that project. Creating the project and minting its first credential is the gap. Only a human login session can do either, and the platform refuses a human session that arrives with an Access service token. The docs say this is deliberate:
- "machine Access proof cannot turn a human Void token into an automation identity" (cli/auth.md)
- "Void does not issue permanent service tokens for administrator automation" (operations.md)
We'd like to know whether you'd support a machine identity for this, and in what shape, before we build anything.
Where it is decided (v1.5.0)
- Access service identities may only reach
/projects/*with a project-scopeddeploy/oauth-deploy/oauth-previewtoken; everything else getsaccess_human_identity_required: platform-access.ts#L106-L121 POST /projectscreates the project for the session's user: projects.ts#L658-L660POST /projects/:id/tokenssigns the credential for the session's user, at most 90 days: project-tokens.ts#L125-L143, deploy-token.ts#L22- The operator API can list, transfer and delete projects but not create them or issue their credentials.
What we would do without it
Create an ordinary user for the service, keep its 30-day Void session and a user Access token in our secret store, and have a person sign in as it about once a month. That works, but it's the pattern the docs above warn against: a human-type account with a password and MFA held by a server, and an outage whenever someone misses the renewal.
Possible shape (for discussion)
An operator registers a machine user and binds it to one Access service token:
void platform machine create lumios --access-service-token <client-id>
- The platform-access middleware admits that service token for a small set of routes when it is paired with the machine user's credential: create a project, issue and revoke credentials for projects the machine user owns, and (maybe) write those projects' secrets.
- The machine credential is revocable and rotatable by an operator, and never works without its bound service token, so leaking one half is not enough.
- Projects it creates count against its plan like any user's, and can be transferred to a human owner with the existing operator command.
Questions
- Is a machine identity something you'd want in Void, or would you rather solve this another way (for example a connected-app grant an administrator approves once, or the GitHub-OIDC executor generalized to other issuers)?
- If machine users: should the credential be long-lived and revocable, or short-lived and exchanged from the bound service token on each use?
- Should projects belong to the machine user, or be created on behalf of a named human owner or team?
- Would you accept a PR once the shape is agreed?
Prepared with an AI coding agent on behalf of @sglyon; reviewed by @sglyon before posting.
- 主要言語
- TypeScript
- スター
- 627
- フォーク
- 66
- 平均マージ
- 13時間 57分
- マージ済み PR（30日）
- 194
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
voidzero-dev/void のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
voidzero-dev/void#677 ·
メンテナーはふだん 1 日以内に返信
-
Export a guard for `VoidActionError` at every status対応中かも @karthickeyan-dev が今日担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 78/100
voidzero-dev/void#714 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
voidzero-dev/void#713 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
`@void/solid`: `useParams()` keeps the first page's params after client-side navigation対応中かも @yujiym が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 20/100
voidzero-dev/void#708 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
voidzero-dev/void#689 ·
メンテナーはふだん 1 日以内に返信
voidzero-dev/void の issue をすべて見る
似ている issue
-
needs-area-label
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
liberation-data/drivine#615 ·
メンテナーはふだん 1 日以内に返信
-
backend bug ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
geolens-io/geolens#3639 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
radius-project/ai-extensions#1196 ·
メンテナーはふだん 1 日以内に返信
-
good first issue
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100