platform: a machine identity that can create projects and issue their deploy tokens

Aberta
  • Algo errado?
#692 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
28/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github, typescript
Domínio
api, authentication

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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-scoped deploy/oauth-deploy/oauth-preview token; everything else gets access_human_identity_required: platform-access.ts#L106-L121
  • POST /projects creates the project for the session's user: projects.ts#L658-L660
  • POST /projects/:id/tokens signs 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
  1. 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)?
  2. If machine users: should the credential be long-lived and revocable, or short-lived and exchanged from the bound service token on each use?
  3. Should projects belong to the machine user, or be created on behalf of a named human owner or team?
  4. 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.

Linguagem predominante
TypeScript
Estrelas
627
Forks
66
Merge médio
13h 57min
PRs com merge (30d)
194

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/void

Todas as issues de voidzero-dev/void

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.