Since #2761, controllers do not, by default, have cluster-wide read permissions on Secrets as they had prior to that PR.
The management controller now dynamically expands the (regular) controllers access to Secrets in Project namespaces only as Projects are created. (Project deletion deletes the corresponding namespace, and with it the relevant RoleBinding.)
Starting with #2761 we also required that RoleBindings that grant controllers read permission on Secrets in "global" credential namespaces be managed manually. The underlying technical constraint driving that is that "global" credential namespaces are user-defined at install-time. While the management controller could, at startup, grant necessary permissions within all those namespaces to the controllers, we elected not to do that because the management controller would have no way of knowing at startup what namespaces might have previously been on that list and have now been removed and therefore cannot know what permissions need to be rescinded. The less than ideal solution was to make this fully the operator's responsibility.
I think there is an opportunity here to automate this and improve UX at the same time:
Add a reconciler to the management controller that watches Namespaces for the addition/removal of a new kargo.akuity.io/global-creds: "true" label and expands/contracts controller permission to read Secrets in those namespaces accordingly.
Deprecate globalCredentials.namespaces and all the mechanisms (env vars, logic, etc.) by which the (regular) controllers learn about this list at startup. It would no longer be needed.
Make (regular) controllers learn the list of global credential namespaces as-needed by listing namespaces having globalCredentials.namespaces.
I do have one concern that could render this idea untenable:
Anyone who can update a given namespace with a new label could indirectly grant Kargo access to that namespace's Secrets even if they, themselves, lack that permission. This would be problematic if that user also has any possibility of obtaining (or creating) an access token associated with a controller's SA.
I think it's at least worth some discussion to see if we cannot overcome that problem somehow.
Since #2761, controllers do not, by default, have cluster-wide read permissions on Secrets as they had prior to that PR.
The management controller now dynamically expands the (regular) controllers access to Secrets in Project namespaces only as Projects are created. (Project deletion deletes the corresponding namespace, and with it the relevant RoleBinding.)
Starting with #2761 we also required that RoleBindings that grant controllers read permission on Secrets in "global" credential namespaces be managed manually. The underlying technical constraint driving that is that "global" credential namespaces are user-defined at install-time. While the management controller could, at startup, grant necessary permissions within all those namespaces to the controllers, we elected not to do that because the management controller would have no way of knowing at startup what namespaces might have previously been on that list and have now been removed and therefore cannot know what permissions need to be rescinded. The less than ideal solution was to make this fully the operator's responsibility.
I think there is an opportunity here to automate this and improve UX at the same time:
Namespaces for the addition/removal of a newkargo.akuity.io/global-creds: "true"label and expands/contracts controller permission to read Secrets in those namespaces accordingly.globalCredentials.namespacesand all the mechanisms (env vars, logic, etc.) by which the (regular) controllers learn about this list at startup. It would no longer be needed.globalCredentials.namespaces.I do have one concern that could render this idea untenable:
Anyone who can update a given namespace with a new label could indirectly grant Kargo access to that namespace's Secrets even if they, themselves, lack that permission. This would be problematic if that user also has any possibility of obtaining (or creating) an access token associated with a controller's SA.
I think it's at least worth some discussion to see if we cannot overcome that problem somehow.