Added additional customer label requesting this support.

What Problem Does this Solve?

This would allow us to dynamically generate the trusted cluster resource with the correct role mappings needed for allowing access between root -> leaf clusters. By having it generated along side the users & roles which the operator can process, this will significantly streamline how we deploy our manifests to leaf clusters that are deployed within kubernetes by reusing our existing CI/CD pipelines. Without this functionality, we would be writing our own sidecar based operator to achieve the same functionality. We have tried using a wildcard mapping on the role_map but this doesn't work because we don't always have the same roles available on every leaf cluster.

Eg: (our roles are globally unique across all clusters, root & leafs)
role_map:

• local: [$1]
  remote: "^(.*)$"

@TeleLos I talked about this with @hugoShaka a while ago and, while doable, adding a trusted cluster resource support to Kube Operator would be a non-trivial amount of work which we likely wouldn't have capacity for in Q2 with all the other goals we've committed to. We can add it to Q3 planning and see if we can schedule it then, would that work?