Spin App: Support ServiceAccountName for underlying Pods

[ThorstenHans]

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 specified ServiceAccountName and run the Wasm workload using the identity.

[radu-matei]

Is it worth considering this as a executor-level configuration?

[ThorstenHans]

That's a fair question.

I was thinking about those scenarios:

• Only a sub-set of your Spin Apps specify PodServiceAccountName at all
• Multiple Spin Apps may provide the same value for PodServiceAccountName

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.

[endocrimes]

@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)

[ThorstenHans]

Azure Workload Identity needs the following label azure.workload.identity/use: "true"

I can lookup what it's actually used for tomorrow morning

[ThorstenHans]

@endocrimes as per this:

https://github.com/Azure/azure-workload-identity/blob/5ad840f6d8ff351141fd0ba7e373eeb7a4d5a52c/charts/workload-identity-webhook/templates/azure-wi-webhook-mutating-webhook-configuration-mutatingwebhookconfiguration.yaml#L27

The mutating webhook of Azure Workload Identity is registered to mutate pods with that label