RBAC v2 role bindings

[bailinhe]

continue work on #245

The API should be updated to use them in place of direct role assignments. The scope of this task is to make the following API changes:

Roles

Create appropriate action relationships from the roles to subject:* type relationships rather than relationships from other resources to the roles

Assignments

Create a binding when creating an assignment rather than creating a direct membership to the role

List both bindings and direct memberships when listing assignments (and show an ID for bindings)

Delete both bindings and direct memberships when deleting assignments

Check permissions based on binding_{create,get,update,delete} actions rather than role-specific actions

See this OpenAPI specs for full list of APIs

[jnschaeffer]

Looks directionally correct so far. A couple of things stick out:

• For mutations, we need to ensure the ZedToken for affected resources gets populated immediately
• We need some kind of locking mechanism similar to LockRoleForUpdate. For mutations on bindings, we will want to lock on both the role and the binding so we don't wind up with situations like trying to create a binding on a role that's being deleted

[jnschaeffer]

This will be good to call out somewhere. From my understanding, this means that if I have the ability to perform a role binding on a resource, I can bind any available role.

One thing we'll want to add next is ensuring that you can only bind roles that have a subset of the actions you yourself can do on that resource. Roughly speaking, I can see that working as something like a bulk check to see that the user performing the binding can perform all of the actions in the role on the resource.

Edit: "add next" = add in a separate PR.

[bailinhe]

This worth some discussions, my thought is that we should allow "IAM admins" to assign any permissions to users under the same OU and its children.

One can argue that "IAM admin" would essentially be a "super user" or owner and I would agree, "IAM admin" is indeed a role that need to be treated very cautiously, but the same goes with "owner" or "super user". And that's where groups come in to provide the flexibility, a group manager will be able to grant certain permissions to users without being an IAM admin.

[jnschaeffer]

More thoughts. Looks better, not sure we need all the complexity around batch deleting role bindings when deleting a role (since I'm not sure we want to support that behavior anyway).

[jnschaeffer]

Looks good! A couple of minor comments before I do some manual testing of this.

[jnschaeffer]

Do we still need this?

[bailinhe]

it also used in rolev2 where we need to grab a bunch of roles, might as well keep it

[jnschaeffer]

Looks good enough for more thorough hands-on testing.