Impersonate ServiceAccount for obtaining source objects

[lennartack]

Feature request Currently, when you set a serviceAccountName in a Kustomization, this ServiceAccount seems to be used only when applying manifests found in the source object. This makes it hard to restrict tenant access to source objects. The --no-cross-namespace-refs option can be used as workaround, but then you can't use the same repository in multiple namespaces (useful to reduce bandwidth usage and reduce infrastructure code complexity).

It would be great if the configured ServiceAccount is used for all operations of the Kustomization, so that we can use Kubernetes RBAC. (And if the source API object is not fetched on every reconcilation, do an API request anyway to check for permissions.)

Documentation bug The documentation (1, 2, and similar for the Helm Controller) does not make clear for which operations the ServiceAccount is used. The definition in the API reference:

The name of the Kubernetes service account to impersonate when reconciling this Kustomization.

This might lead administrators to believe that impersonation is done for all operations when reconciling, including obtaining the source object.