Epic #49
open
Implement user, groups and permissions management
43%
Description
Anyone with an account can currently do anything the platform exposes. Administrators need to decide who may do what, and people who own a server need to share access to it without handing over the whole installation.
This epic covers what the platform knows how to authorise, who can be given access, how access is given, how it is decided and enforced, how it can be understood afterwards, how accounts are administered, and how agents and modules prove who they are.
The model, in short:
- A permission is a named capability, for example "restart a Minecraft server". Permissions are contributed by the platform itself and by installed modules.
- A role is a reusable named set of permissions. A group is a named set of users and holds no permissions of its own.
- Access is given by granting a role, or a hand-picked set of permissions, to a user or a group — either across the whole platform or on one specific object.
- Three states exist: allowed, denied, not set. Not set is not the same as denied.
- The grant closest to the object decides. Within one place, an entry naming the person beats one naming a group they are in, and a denial beats an allowance. Anything not decided is refused.
- Administrators (holders of the all-permissions role) are never refused, and the last of them cannot be removed.
- Nobody can give away access they do not hold themselves.
Out of scope here, tracked separately: folders and the inheritance that comes with them, storing and browsing an audit trail (this epic only emits the events), bulk operations (#305), and hosting several organisations on one installation.
Full specification: kubestro-permissions-report.md.
Files
Updated by Bricklou 15 days ago
Design note from the #163-adjacent authorization work (moving permission checks into use cases instead of only at the API layer):
Agents are controlled through the API, the same way kubelets are controlled through a kube-apiserver — they're command-executors, not independent actors that evaluate user permissions themselves. The control plane (this API) decides authorization before ever issuing work to an Agent. Consequences for this epic's design:
- Permission checking never needs to be shared with or verified by Agents at all — it stays fully centralized in the API, the same way Kubernetes RBAC never runs on the kubelet.
- Agent trust is a separate axis: agent identity/authentication (analogous to kube's Node authorization / bootstrap tokens / client certs), not permission-checking. An Agent needs to prove it's a legitimate registered Agent of this control plane; it never needs to know what a human user is allowed to do.
- Still open for this epic: the Agent registration/handshake protocol and what credential an Agent authenticates with — a separate problem from user permission-checking.
Also: permissions should be modeled as open, string-identified capabilities each module declares locally (e.g. "users:manage"), not a single shared enum — a closed enum in one crate has the same fixed-set problem a role enum has, just one level up, and doesn't let future modules define their own permissions without touching shared code.
Updated by Bricklou 15 days ago
- Blocks User Story #264: As an administrator, I want to create a user account directly with a temporary password, so that I can onboard someone without sending an email added
Updated by Bricklou 15 days ago
- Blocks User Story #263: As an administrator, I want to invite a new user by email, so that they can activate their own account added
Updated by Bricklou 9 days ago
- File kubestro-permissions-report.md added
- File kubestro-permissions-report.md kubestro-permissions-report.md added