Add list users API endpoint and UI page

[benoit-nexthop]

Summary

Adds a GET /api/v1/users endpoint to list all users, plus a Users page in the webapp UI.

Changes

• Add ListUsers to the database store and runner layers
• Add ListUsersHandler and register /users routes
• Add listUsers() to the webapp API client
• Add a Users page to the webapp, linked from the navigation sidebar

Notes

This endpoint is admin-gated the same as every other endpoint under apiRouter (via AdminRequiredMiddleware) — no change to authorization behavior is included here.

Testing

Tested in staging and production environments.

[gabriel-samfira]

Hi @benoit-nexthop

I owe you a more detailed answer on the multi-user support story.

The reason this doesn't exist yet is because GARM is not really multi user aware yet. Adding multi-user support has not been planned yet as GARM itself was not designed to be a large scale SaaS solution. We've always recommended multiple GARM deployments, if separate teams needed more control, rather than one big deployment.

Adding multi-user support means defining resource ownership and how it should look for all of GARMs current resources (endpoints, credentials, repos, orgs, enterprises, foge instances, scale sets, pools, templates, objects, etc). Some of these will be shared, some will only be definable by admins, some should be definable by regular users, etc. Sharing resources are a whole discussion that needs to happen, but it is one we need to get right when we implement multi-user support, otherwise it will be difficult to change later and after a huge effort to add multi-user support, not a desirable outcome to have.

That being said, it's not out of the question to add multi-user support, but it is a huge undertaking to do right and there are a lot of code paths that we need to take into account, as well as UX, proper permission design, RBACs, potentially a policy engine, shared resources (ie: runner install templates, endpoints). To do it right, we'd need a proper design session done or a blueprint to be written and probably many PRs spread across a long period of time.

---

If you only need to grant some parties the ability to use some API endpoints, with certain verbs (GET/POST/PUT/DELETE), then perhaps multi-user support is overkill, and we can look into implementing a policy engine and generate tokens scoped to specific resources and actions. Similar to how GitHub PATs work. Something like, generate a token that can:

• pools:read - list pools
• instances:* - all operations on individual instances
• scalesets:read,update - read and update scale sets but not delete
• *:read - read on all resources

Tokens can be revoked, access can be implemented in the auth middleware without touching any other code path or worry about resource ownership. All tokens would be "admin", but not all tokens would be able to run the same operations.

Resource scoped tokens are fairly low impact to implement, but do not offer granularity like:

• allow operations only on instances in pool X
• instances in repo Y regardless of pool/scale set

And we would still need to figure out how to expose that to the CLI and Web UI.