Role Based Access Controls (RBAC) Schema & Design

[eeyun]

Role-Based Access Controls

Builder users have very little flexibility in the operational concerns and controls for any origins that they own. Currently there only exist 2 types of builder users: Owners, and Non-Owners. What's more, the only difference in these users permissions is that Owners can delete the origin, can transfer ownership of the origin, and can remove current users. Non-Owners retain all other authorizations including uploading/rolling keys and packages and adding users. This is clearly less than ideal since it limits the ways that users can leverage the tools.

A goal of this work (and this doc) is to provide more control over various operations in builder in a way that supports several different use-cases. *Primarily any output from this work should resolve #1149 as the principle target, preferably any implementation would be flexible enough that extending it to cover other use cases.

Motivation

As a user of both SaaS and On-prem builder I want to be able to control who has access to the multitude of available operations that can be performed from package uploads to key visibility and membership management.

Specification

For the sake of an initial implementation the primary goal is to get a backend architecture that can be extended past a single "role" however our initial goal and expected output for this work is to provide the 'Origin Member' role listed below and any crud operations associated with the new primitive of 'Roles'. It is most likely that this design doc will generate MULTIPLE tickets and an overarching epic.

In our early discovery we're looking at extending our authz function https://github.com/habitat-sh/builder/blob/master/components/builder-api/src/server/authorize.rs#L26-L77 as the entrypoint for any types of behaviors.

We know at the database layer that origin_members will need a new column of role that exists as an enum with the possible entries of owner, administrator, maintainer, member. For current users, any migration that comes as an outcome of this work should not alter existing authorizations, all currently existing origin members today align with the listed origin administrator role listed below so all existing users will be assigned that role. Origin owners will have to manually alter their members to reduce their permissions to the new origin member role.

Roles

We wanted to break down the list of potential user identity "roles" here before we determine architecturally what the implementation looks like. This should inform the implementation really.

Action	Read-Only	Member	Maintainer	Administrator	Owner
Packages
View packages	Y	Y	Y	Y	Y
Upload packages to unstable	N	Y	Y	Y	Y
Promote packages from unstable	N	N	Y	Y	Y
Build Jobs
View build jobs	Y	Y	Y	Y	Y
Trigger unstable build job	N	Y	Y	Y	Y
Channels
View channels	Y	Y	Y	Y	Y
Add/Update/Delete channels	N	N	Y	Y	Y
Origin Keys
View keys	Y	Y	Y	Y	Y
Add/Update/Delete keys	N	N	N	Y	Y
Origin Membership
View members	Y	Y	Y	Y	Y
View invitations	Y	Y	Y	Y	Y
Send Invitations	N	N	Y	Y	Y
Revoke Invitations	N	N	Y	Y	Y
Member Roles
View member roles	Y	Y	Y	Y	Y
Update member roles	N	N	N	Y	Y
Origin Settings
View settings	Y	Y	Y	Y	Y
Add/Update/Delete settings	N	N	N	Y	Y
Origin Secrets
View secrets	N	N	N	Y	Y
Add/Update/Delete secrets	N	N	N	Y	Y
Cloud Integrations
View integrations	Y	Y	Y	Y	Y
Add/Update/Delete integrations	N	N	Y	Y	Y
Ownership
Transfer Origin	N	N	N	N	Y
Delete Origin	N	N	N	N	Y

Another way to look at it:

Role	Permissions
Origin Read-only Member	Read (packages, channels, members, jobs, keys, integrations, invitations, roles, settings)
Origin Member	Read (packages, channels, members, jobs, keys, integrations, invitations, roles, settings) Write (packages, jobs)
Origin Maintainer	Read (packages, channels, members, jobs, keys, integrations, invitations, roles, settings), Write (packages, channels, members, jobs, integrations, invitations, settings)
Origin Administrator	Read (packages, channels, members, jobs, keys, integrations, invitations, roles, secrets, settings), Write (packages, channels, members, jobs, keys, integrations, invitations, roles, secrets, settings)
Origin Owner	All operations permitted including origin deletion

*As a follow on PR these roles will be differentiated further. As noted in the rest of this doc we are, for our initial slice, focusing on the member role and an extensible privilege system.

Downstream Impact

Theoretically, any changes made in the initial implementation should be entirely transparent to end-users. In fact, since the UI work to fully support this featureset won't have been implemented, even the ability leverage the change will be fairly hidden from those end-users.

Validation of downstream impact will be partially determined through our functional test suite. All of existing tests are expected to work top to bottom. A new suite of tests will need to be added to validate that the new origin member role does not have access to all of the actions and resources that the origin owner/administrator does.

Finally, we will want to verify all end-user behaviours and functionality in acceptance before a release is cut.

Related Issues

#1149
#1142
#1301
#835

[apriofrost]

@eeyun @krasnow First design iteration mockup: https://chef.invisionapp.com/share/M7X9HIZFP5Z#/417375859_origin-Members
The goal is to use it as a way of asking probing questions to users in the coming research sessions.

[eeyun]

Dang, that is 🔥. So good @apriofrost!

[apriofrost]

After chatting with @krasnow , we decided to move forward with this design direction with the UI team for implementation. I'm working on fleshing out some of the design details for a complete user journey.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically closed after being stale for 400 days. We still value your input and contribution. Please re-open the issue if desired and leave a comment with details.