Open ThorstenHans opened 5 months ago
Is it worth considering this as a executor-level configuration?
That's a fair question.
I was thinking about those scenarios:
PodServiceAccountName
at allPodServiceAccountName
A great argument for putting it on the executor would be that it slightly moves the responsibility away from the developer towards Ops.
If we move PodServiceAccountName
to the executor, people should also be able to inject Pod Labels on the scope of the executor, because Azure Workload Identity requires both Pod Labels and ServiceAccountName to work.
@ThorstenHans Do you know what the labels are used for? - In GKE you just need the serviceAccountName (and a iam.gke.io/gke-metadata-server-enabled: "true"
nodeSelector in the runtime class)
Azure Workload Identity needs the following label azure.workload.identity/use: "true"
I can lookup what it's actually used for tomorrow morning
@endocrimes as per this:
The mutating webhook of Azure Workload Identity is registered to mutate pods with that label
Being able to specify the
ServiceAccountName
for underlying Pods is necessary to unlock capabilities - such as Azure Workload Identity - provided by managed Kubernetes distros (e.g. AKS).Obviously, the underlying runtime (
containerd-shim-spin
) must pick up the specifiedServiceAccountName
and run the Wasm workload using the identity.