mirror of
https://github.com/coder/coder.git
synced 2025-03-14 10:09:57 +00:00
cccdf1ecac
Using negative permissions, this role prevents a user's ability to create & delete a workspace within a given organization. Workspaces are uniquely owned by an org and a user, so the org has to supercede the user permission with a negative permission. # Use case Organizations must be able to restrict a member's ability to create a workspace. This permission is implicitly granted (see https://github.com/coder/coder/issues/16546#issuecomment-2655437860). To revoke this permission, the solution chosen was to use negative permissions in a built in role called `WorkspaceCreationBan`. # Rational Using negative permissions is new territory, and not ideal. However, workspaces are in a unique position. Workspaces have 2 owners. The organization and the user. To prevent users from creating a workspace in another organization, an [implied negative permission](36d9f5ddb3/coderd/rbac/policy.rego (L172-L192)) is used. So the truth table looks like: _how to read this table [here](36d9f5ddb3/coderd/rbac/README.md (roles))_ | Role (example) | Site | Org | User | Result | |-----------------|------|------|------|--------| | non-org-member | \_ | N | YN\_ | N | | user | \_ | \_ | Y | Y | | WorkspaceBan | \_ | N | Y | Y | | unauthenticated | \_ | \_ | \_ | N | This new role, `WorkspaceCreationBan` is the same truth table condition as if the user was not a member of the organization (when doing a workspace create/delete). So this behavior **is not entirely new**. <details> <summary>How to do it without a negative permission</summary> The alternate approach would be to remove the implied permission, and grant it via and organization role. However this would add new behavior that an organizational role has the ability to grant a user permissions on their own resources? It does not make sense for an org role to prevent user from changing their profile information for example. So the only option is to create a new truth table column for resources that are owned by both an organization and a user. | Role (example) | Site | Org |User+Org| User | Result | |-----------------|------|------|--------|------|--------| | non-org-member | \_ | N | \_ | \_ | N | | user | \_ | \_ | \_ | \_ | N | | WorkspaceAllow | \_ | \_ | Y | \_ | Y | | unauthenticated | \_ | \_ | \_ | \_ | N | Now a user has no opinion on if they can create a workspace, which feels a little wrong. A user should have the authority over what is theres. There is fundamental _philosophical_ question of "Who does a workspace belong to?". The user has some set of autonomy, yet it is the organization that controls it's existence. A head scratcher 🤔 </details> ## Will we need more negative built in roles? There are few resources that have shared ownership. Only `ResourceOrganizationMember` and `ResourceGroupMember`. Since negative permissions is intended to revoke access to a shared resource, then **no.** **This is the only one we need**. Classic resources like `ResourceTemplate` are entirely controlled by the Organization permissions. And resources entirely in the user control (like user profile) are only controlled by `User` permissions. ![Uploading Screenshot 2025-02-26 at 22.26.52.png…]() --------- Co-authored-by: Jaayden Halko <jaayden.halko@gmail.com> Co-authored-by: ケイラ <mckayla@hey.com>
18 lines
741 B
Go
18 lines
741 B
Go
package codersdk
|
|
|
|
// Ideally this roles would be generated from the rbac/roles.go package.
|
|
const (
|
|
RoleOwner string = "owner"
|
|
RoleMember string = "member"
|
|
RoleTemplateAdmin string = "template-admin"
|
|
RoleUserAdmin string = "user-admin"
|
|
RoleAuditor string = "auditor"
|
|
|
|
RoleOrganizationAdmin string = "organization-admin"
|
|
RoleOrganizationMember string = "organization-member"
|
|
RoleOrganizationAuditor string = "organization-auditor"
|
|
RoleOrganizationTemplateAdmin string = "organization-template-admin"
|
|
RoleOrganizationUserAdmin string = "organization-user-admin"
|
|
RoleOrganizationWorkspaceCreationBan string = "organization-workspace-creation-ban"
|
|
)
|