What this does

This dropsresource_id from the RBAC permissions. This is a loss of a feature from RBAC. The goal is to reduce complexity of the rego policy, and reduce the number of permissions on actors.

At the present, noresource_id permissions are used. So this removes excess functionality that has no real planned use in the current roadmap.

Why did we have resource_id?

Intended to support:

• Workspace agent tokens
  • This is handled outside the RBAC permission system
• Roles as a resource (solved)
  • Solution needs to be determined. This intended solution was building a graph using permission nodes. Although "clean" from an additional code perspective, visualizing and displaying the output of this was going to be a challenge. It is likely easier to just build static lists of approved assign/remove roles for each role.
  • We can still implement this making each role a unique resource type.
• Workspace sharing (ACL lists on object?)
  • Solution was to assign permission nodes to other users to share my workspace?? This solution was technically supported, but a bit convoluted as it requires assigning permissions to another user. It would also be hard to list all users that this workspace is shared with.

What do we gain?

By removingresource_id, there is only 3 properties of an object we need to knowAuthorize?:object_type,owner_id, andorg_owner. This reduction only removes 1 property, but drastically reduces the number of unique objects in the system. This can drastically speedupAuthorize() calls on large sets and enables future optimizations.

Can we revert this?

Yes. We can revert this, however I don't recommend we doPhase 2.

I think it is better to have a need arise and implement this back, then have this feature be available and possibly misused because it is "just there".

What this does not do

This does not reduce RBAC authorization benchmarks.