Is your feature request related to a problem? Please describe.
When importing CAPI-provisioned clusters via Turtles, the Rancher cluster resource are generated and there are errors related to creatorId, like the following:
When importing the same cluster via the "standard" Rancher way, the creatorId annotation is populated with a valid users.management.cattle.io and the error is gone.
The issue is that Turtles (as part of it's operation) creates a mgmt cluster. There is functionality which gives the user who creates this CRD default bindings (usually to cluster-owner). However, in the turtles case, this user is a service account, and our RBAC doesn't work for service accounts. So we get error logs as our handlers spin and can't process the user.
Describe the solution you'd like
Provide a method for users to bypass the default bindings, possibly by adding an annotation to the cluster.
Describe alternatives you've considered
Instead of explicitly adding an annotation to the cluster, the default bindings could be bypassed based on the user type when importing a cluster. Generally, RBAC rules and bindings are preferred to be explicit. Otherwise that implicit logic if not well maintained can lead to CVEs.
Perhaps another solution would be to have RBAC work with Service Accounts. This needs more research if it's even feasible as it may not be supported by Kubernetes.
JonCrowther
commented
2 months ago
Is your feature request related to a problem? Please describe. When importing CAPI-provisioned clusters via Turtles, the Rancher cluster resource are generated and there are errors related to
creatorId, like the following:When importing the same cluster via the "standard" Rancher way, the
creatorIdannotation is populated with a validusers.management.cattle.ioand the error is gone.The issue is that Turtles (as part of it's operation) creates a mgmt cluster. There is functionality which gives the user who creates this CRD default bindings (usually to cluster-owner). However, in the turtles case, this user is a service account, and our RBAC doesn't work for service accounts. So we get error logs as our handlers spin and can't process the user.
Describe the solution you'd like Provide a method for users to bypass the default bindings, possibly by adding an annotation to the cluster.
Describe alternatives you've considered Instead of explicitly adding an annotation to the cluster, the default bindings could be bypassed based on the user type when importing a cluster. Generally, RBAC rules and bindings are preferred to be explicit. Otherwise that implicit logic if not well maintained can lead to CVEs.
Perhaps another solution would be to have RBAC work with Service Accounts. This needs more research if it's even feasible as it may not be supported by Kubernetes.
Reproduction