Allow setting a default service account for impersonation

[stefanprodan]

Introduce the flag --default-service-account for allowing cluster admins to enforce impersonation across the cluster without having to use an admission controller.

When the flag is set to a value that's not empty string, all Kustomizations which don't have spec.serviceAccountName specified, they will use the service account name provided by --default-service-account=<SA Name> in the namespace of the object.

Breaking changes:

• When --default-service-account=<SA name> and/or spec.ServiceAccountName are specified, the controller no longer queries the API to extract and use the SA token. Instead, the controller relies on the Kubernetes impersonation feature to run the reconciliation under the system:serviceaccount:<SA Namespace>:<SA Name> identity. This impacts only clusters with custom made tokens and automountServiceAccountToken disabled. If a service account token points to a different identity (which should never be the case), then the controller will fail to reconcile with Forbidden : User "system:serviceaccount:my-namespace:my-sa-name" cannot patch resource.
• When both spec.kubeConfig and spec.ServiceAccountName are specified, the controller will impersonate the service account on the target cluster, previously the controller ignored the service account.

Fix: #422
Part of: fluxcd/flux2#2340

[squaremo]

• When --default-service-account=<SA name> and/or spec.ServiceAccountName are specified, the controller no longer queries the API to extract and use the SA token. Instead, the controller relies on the Kubernetes impersonation feature to run the reconciliation under the system:serviceaccount:<SA Namespace>:<SA Name> identity.

I'm not clear on how this is a breaking change -- isn't the result the same?

[stefanprodan]

I'm not clear on how this is a breaking change -- isn't the result the same?

Indeed the result is the same, but the operations needed to achieve the result have drastically changed.

[squaremo]

Indeed the result is the same,

So does it break anything?

[stefanprodan]

So does it break anything?

Yes, if people have disabled the automated token creation for their service accounts, and they are setting the token in the attached secret by hand, then this PR will break their setup, as we no longer use tokens.

[squaremo]

if people have disabled the automated token creation for their service accounts, and they are setting the token in the attached secret by hand, then this PR will break their setup, as we no longer use tokens.

That's what you should say in the description (commit, docs, changelog) :-)