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

Abierto
  • ¿Algo no está bien?
#692 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github, typescript
Área
api, authentication

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
627
Forks
66
Merge medio
13 h 57 min
PR fusionados (30 d)
194

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de voidzero-dev/void

Todos los issues de voidzero-dev/void

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.