Support wildcards in additionalrolebindings section of Tenant specification

[meetdpv]

Describe the feature

additionalrolebindings section of Tenant specification needs an exact user. It does not support wildcard for user.

What would the new user story look like?

Support wildcards in additionalrolebindings section of Tenant specification

How would the new interaction with Capsule look like? E.g.
We are using Capsule on EKS. While defining tenant, we would like to assign additional roles to a group of users which can be achieved by wildcard instead of listing all of them in the specification.

Existing specification
spec:
owners:

• name: alice
  kind: User
  additionalRoleBindings:
• clusterRoleName: EKS-Viewer-ClusterRole
  subjects:
  • apiGroup: rbac.authorization.k8s.io
    kind: User
    name: EKS-User:<<aws_account_id>>:user_1

Feel free to add a diagram if that helps explain things.

Expected behavior

Support wildcards in the users section of additionalrolebindings to support large team.
spec:
owners:

• name: alice
  kind: User
  additionalRoleBindings:
• clusterRoleName: EKS-Viewer-ClusterRole
  subjects:
  • apiGroup: rbac.authorization.k8s.io
    kind: User
    name: EKS-User:<<aws_account_id>>:user_* (wildcard)

[prometherion]

Thanks for the feature proposal.

Unfortunately, this is not feasible since Kubernetes itself doesn't support RBAC. Furthermore, a wildcard introduces potential issues from a security standpoint.

If you can elaborate a bit more your use-case as well as your struggles, by adding a detailed user-story, we can definitely try to understand if it can potentially fit into the Capsule area.

[oliverbaehler]

@prometherion One Use-Case which is interesting, would be allowing to have wildcards in respected userGroups in the capsuleConfiguration. system:serviceaccount:*-system:gitops where * would be the tenant name. This simplifies gitops integrations, where serviceaccounts should be able create namespaces. This is also possible with eg system:serviceaccounts:tenants, where you create a new serviceaccount per tenant in the tenants namespace. However you also have to create a manual rolebinding, so the users could see their syncs.

But we should probably stick to the native xperience.

[prometherion]

But we should probably stick to the native experience

That was the Capsule aim from day one: with all due respect to the feature request, which are always welcome, it seems to me a workaround to a different problem that should be addressed in a different scope.