What this does

This allows making scopes for specific resources to support workspace agent tokens. This PR is a prerequisite to pushing RBAC authz checks to the db layer. When authz checks are pushed down, workspace agent tokens will conform to the same RBAC as users. To prevent workspace agent tokens from having more access than required, we need to limit the token to a single workspace, and ideally do this in the authz.

Implementation

Add an allow_list to the scope section to specify particular resources. User scopes will almost always have an allow_list = ["*"].

I have not added the code to add resource ids to scopes yet. It is not yet in use and the plumbing can be pushed off. Currently users can define scopes when making api keys, tbd if we should give them access to this or only use it internally.

Performance

Originally our RBAC supported an id field in permissions. It was removed as it added complexity that would impact performance, especially at scale. If permissions can specify individual resource IDs, it could be heavily used compounding the number of permissions required to be checked for each authz. The resource ID check also makes partial evaluation increase in complexity and adds id = ANY(ARRAY ['id-1', 'id-2', ...])) to all SQL filters. Performance of RBAC authz checks is critical to user experience, so the extra complexity was dropped.

To support the edge cases where this is required, we can limit the additional complexity by adding it as a field on the scope. Only 1 scope can be applied, so this list is always going to be explicitly set once, rather than being a combination of multiple roles.

The additional cost is to be negligible for all current authz costs. The benchmarks show that using the all scope has no impact. The rego check is very quick:

scope_allow_list {
	"*" in input.subject.scope.allow_list
}

For partial evaluations, the rego check is designed to add 0 additional queries and 0 additional terms to existing queries if * is in the allow_list:

scope_allow_list {
	# If the wildcard is listed in the allow_list, we do not care about the
	# object.id. This line is included to prevent partial compilations from
	# ever needing to include the object.id.
	not "*" in input.subject.scope.allow_list
	input.object.id  != ""
	input.object.id in input.subject.scope.allow_list
}

If the allow_list is used, performance on authz call in memory will likely not be impacted (TODO confirm). SQL filters will have additional queries and terms in the existing queries (TODO eval sql impact).

Plumbing

Part of this plumbing is making sure ID is included in RBAC objects sent to authorize. This will be much easier to conform and find instances when the intermediate layer between the db is implemented.

Until then, I am manually tracking down all cases. If a case is missed, it will fail secure.

Future

If this implementation is too limited for the future, we investigate alternative more complex solutions. Migrating this to another implementation will not be challenging imo. This is an incredibly simple approach to solving this issue. Since the set of scopes is currently a finite hard coded set, it gives a lot of flexibility in handling any migration.

Tl'dr: We are not coding ourselves into a corner here.

Notes

• ProvisionerDaemons are not currently org scoped resources. Should associate them to an org?