Proposal: scoped API tokens and roles

[sumansaurabh]

The problem

The operator token can do everything on a server. It can create and delete any sandbox, read any sandbox's environment variables and run commands in any sandbox. You cannot give a CI job a token that only creates sandboxes, or give a teammate one that can only read.

What you can do today

Put your own service in front of AerolVM and decide there who can do what. Keep the operator token inside that service.

A starting shape

The API's auth layer already tells two kinds of callers apart: the operator, who sees everything, and an owner-scoped caller, who sees only their own sandboxes. The open-source build only accepts the operator token today. The proposal fills in the second kind:

• Tokens the operator creates, each tied to an owner, with an optional expiry date. A token can be revoked on its own.
• Three roles to start: viewer (read status and logs), runner (create, run commands, delete its own sandboxes), and admin (everything, like the operator token).
• Owner scoping: a runner sees only the sandboxes its owner created.
• Audit: every record names the token that made the call. See the caller identity proposal.

Questions for you

1. Are the three roles enough? What would you add?
2. Should a token be scoped by owner, by sandbox tags or by both?
3. Do you need tokens that can only reach some runtimes, such as Firecracker only?
4. How do you want to manage tokens: the CLI, the dashboard or an API?

How to weigh in

React with 👍 if you need this, and comment with your answers.

Want to talk it through? Book a call with the maintainer, or join the community call on the first Saturday of every month at 8 pm Pacific Time.

If your company needs this soon, you can sponsor the work. It is built in the open and ships to everyone.

[sumansaurabh]

Thanks for proposing this. It shipped in v0.6.8, together with SSO (#647)
and caller identity in audit records (#649), as one feature: access control.

What you get:

• Scoped API tokens. An admin creates a token with a name, a role, a team
  and an expiry: aerolvm token create --name ci-deploy --role runner --team payments --expires-in 90d, or tokens.create(...) in all five SDKs. The
  secret (avm_…) is shown once and stored only as a hash. Every token
  expires (365 days at most by default, 90 in enterprise mode). A revoke
  reaches every server in a cluster within about 5 seconds.
• Four roles: viewer (read), runner (create, run, delete, read env),
  auditor (read every team's sandboxes and audit records, never change
  anything) and admin. viewer and runner can be bound to one team or to
  every team.
• Teams. A team's sandboxes belong to it. Another team's sandbox answers
  404. A role that is too small gets a 403 that names the role you would
  need.
• A read-only scrape credential. A viewer on every team can read
  /v1/metrics, so Prometheus no longer needs the server token. It is
  read-only, not metrics-only: it can also read every team's sandbox details
  and audit records.
• Enforcement. SB_PAT_SCOPE=host limits the shared server token to the
  server itself and cluster servers, so remote callers must use a named
  credential. Enterprise mode requires it.

It is off by default (SB_IDENTITY_ENABLED=true turns it on), and a server
with it off behaves exactly as before. Tokens-only mode needs no identity
provider, so it works air-gapped.

Docs: https://microvm.aerol.ai/enterprise/sso/

Not in this release: custom roles and per-sandbox permissions (four fixed
roles for now), and per-team quotas, which can now build on teams (#648).
If you need either, please say what you would use it for below.