Access tokens currently inherit the full set of permissions from their owners. We'd love to be able to limit the routes that can be accessed by an individual token.
Since predefined scopes are difficult to get right, we propose to instead support a path-based allowlist for a token (as a multiline plain text) in the "Create API Token" modal, where each line specifies an allowlisted route, possibly with wildcards for individual segments. Example:
GET /api/v1/cloudron/graphs GET /api/v1/notifications GET /api/v1/notifications/* GET /api/v1/apps/*/logs
Note: The inclusion of the base path and syntax for wildcards or patterns may need some further discussion.
- Custom dashboards: We created a custom dashboard in Observable where we consume the
cloudron/graphsroutes. This dashboard cannot currently be shared with users who have a lower access privilege as it would expose an admin-level token.
- CI/CD hardening: We are currently investigating how we can reduce the risk of privilege escalation in a CI/CD environment. An admin-level token is currently used to create and tear down staging apps, and to configure their aliases. Once Cloudron 6.4 has been released we might also assign operators this way. Restricting routes may offer some level of risk reduction should a user gain access to the token.
We might be able to set up an HTTP proxy as API middleman. The proxy would be configured with an admin-level token, but would manage an internal set of tokens with their own set of retrictions.