1. Proposed title of this feature request

Allow assigning multiple ACS roles to users/groups

2. What is the nature and description of the request?

In ACS when creating Rules to assign roles to users, ACS only allows one key/value combination to be assigned to a role. ACS does appear to support multiple roles being in play for a single user if different key/value mappings are used however it restricts the mapping to one role per key/value combination.

This RFE is to remove this restriction so that you can have the same key/value multiple times with different roles being assigned allowing role aggregation.

3. Why does the customer need this? (List the business requirements here)

Customers are coming from k8s where subjects can have many different roles assigned to them via RoleBinding and ClusterRoleBinding. As a result for these customers it's not always easy to map these roles into ACS to enable user access since it devolves into a situation where you start having to create a large number of per user roles in order to get the access scopes correct.

For example, take a customer operating a large multi-tenant cluster where developers can be assigned to multiple projects over time. The customer wishes to give these developers access in ACS to the projects they have worked on which means each developer requires very specific access scopes reflecting the projects in the cluster they have worked on. In k8s this is easy since you can have separate but aggregated RoleBindings meaning one rolebinding for access to namespace A and another rolebinding for access to namespace B.

In ACS we don't appear to be able to do this which requires rolling up these access scopes into a role that is specific for a particular user. In clusters with hundreds of namespaces and thousands of users this will not scale. While one could create groups as the aggregation tool this becomes very messy for customers to manage and stay synchronized.

ACS does appear to support multiple roles being assigned to a user if the key/value is different but still matches the user. However if you attempt to add a new rule with a key/value for a new role that matches an existing rule key/value pair it simply overwrites the existing rule. This appears to be the case both in the UI and in the API.

Longer term the plan is for ACS to leverage the k8s rolebindings to determine access scope, however removing this restriction in the short term would make things a lot more flexible for customers.

4. List any affected packages or components.

Roles and Access Scopes