Scope RBAC roles by label

[calebhailey]

Add support for new resource_labels attribute (using "labels" as selectors), similar to how resource_names works, but offering a more dynamic mechanism for granting access to some subset of resources.

https://github.com/sensu/sensu-go/blob/0eca3eff1d9621e1cde4c71901875a4a8922cc48/api/core/v2/rbac.proto#L28-L30

[annaplotkin]

Primary use cases:

1. You wish to give users access to specific resources in a namespace but not an access to ALL resources.
2. You have ephemeral infrastructure and your resource_names may not match and be effective after infrastructure is blown away

This would be used as an OR to resource_names and not in conjunction.

[portertech]

Further context. A resource name must be unique to the resource (for a type). Resource labels do not need to be unique, providing a better RBAC policy binding attribute for dynamic environments and configuration.

I would like to understand the performance impact, as there will be a cost incurred on every Agent connection and API request.

[echlebek]

This is a great feature idea, as we'll be able to apply a single RBAC role to multiple specific resources with different names.

We need to understand the larger implications around resource creation, listing, and operations other than simple "get" here.

Cameron points out that this is similar to the classic subscriptions model, and there are some known issues there.

A meeting should be scheduled to discuss the issue in detail.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[echlebek]

Looks like we never had a meeting about this. It occurs to me now that it might allow people to subvert security in some cases.

Is there still interest in this? Re-open if yes!

[calebhailey]

It occurs to me that resource_labels would make a lot of sense for read/update/delete roles, but not for create roles.