Support Azure AD Workload Identity

[berndverst]

This depends on https://github.com/Azure/azure-sdk-for-go/issues/15615

Once the Azure SDK for Go azidentity library has this support we need to update our dependency and should get this feature for free.

I'd roughly estimate this to go into Dapr release 1.9, primarily because the azidentity team estimates this work to be done in May at the earliest.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[berndverst]

Currently the Azure Identity SDK will introduce Workload Identity support sometime in January (if this doesn't slip further). Given the Dapr 1.10 release early February it is unclear whether we can release Workload Identity support in 1.10. 1.11 is looking more likely, but we will certainly try.

FYI @ItalyPaleAle

[karoldeland]

@berndverst Will it be for all components? Should we expect to have a progressive support starting in 1.11?

[ItalyPaleAle]

@karoldeland we're waiting to see how the SDK team implements it, but my hope is that it will allow us to support all (or most) Azure components right away

[stuartleeks]

Is there any update on the progress of this? Does this PR on the Go SDK add the support needed to add Workload Identity to Dapr?

It looks like azidentity v1.2.0 is the referenced version, which predates the Workload Identity PR being merged. Are there any plans to update to azidentity 1.2.1 for the 1.10 release?

Thanks!

[berndverst]

Is there any update on the progress of this? Does this PR on the Go SDK add the support needed to add Workload Identity to Dapr?

It looks like azidentity v1.2.0 is the referenced version, which predates the Workload Identity PR being merged. Are there any plans to update to azidentity 1.2.1 for the 1.10 release?

Thanks!

I'm working on this now - but we will only releases this in a future Dapr release once AzIdentity (the Azure Go SDK we need) v1.3.0 is released - the first stable release containing this feature @stuartleeks. As of now that SDK is not released, but it should be released in time for Dapr 1.11 in May. In a few days this feature should be available in our nightly builds however (unsupported! -- For development purposes we are using v1.3.0-beta.3 now)

[berndverst]

@berndverst Will it be for all components? Should we expect to have a progressive support starting in 1.11?

@karoldeland at this time we support all Azure AD authentication mechanisms for all Azure components. Once I complete the Workload identity implementation it will automatically be available for all Azure components.

[berndverst]

To use this feature the following will be necessary.

Set up as outlined here: https://learn.microsoft.com/azure/aks/workload-identity-deploy-cluster

Your pod / deployment must have the following label: azure.workload.identity/use: "true"

That is all that needs to be done. Assuming the pod / deployment is associated with a Kubernetes service account which is workload identity configured, this should automatically inject everything required for Dapr to authenticate using workload identity.

One problem I can foresee (and I do not have the answer right now): The assumption is that the Workload Identity Mutating Webhook will inject the required environment variables and values into all containers of the Pod (including the Dapr sidecar). However it is unclear at the moment whether the Sidecar Injector mutating webhook executes before or after the workload identity webhook. Kubernetes guarantees no ordering.

I opened an issue against the workload identity project to ensure they set the correct Kubernetes (reinvocationPolicy: IfNeeded) on their webhook.

https://github.com/Azure/azure-workload-identity/issues/787

[berndverst]

Quick update here:

I opened another bug https://github.com/Azure/azure-workload-identity/issues/791

In my testing AKS Workload Identity was applied before the Dapr sidecar (or any sidecar for that matter) was injected. As a result the Dapr sidecar cannot get the information it needs to authenticate using Azure workload identity.

I spoke with the Engineering and PM team about my proposed solution in https://github.com/Azure/azure-workload-identity/issues/787. The team is looking into this, but it will take some time.

With that in mind, even though the Dapr work to implement Workload Identity is complete - it is not yet usable.

Connecting to an Azure service using Workload Identity from an injected container (sidecar) is a bit uncommon after all 😄

[stuartleeks]

Thanks for the updates @berndverst!

Would it be worth re-opening this issue as a clearer statement that workload identity isn't currently usable? (i.e. to prompt people to read down the comments rather than assuming that it's implemented and working)

[berndverst]

@stuartleeks the attached milestone is an indication of which release has the feature. We use the issues as work items and close them when completed.

As an aside, technically you can already deploy workload identity manually via the OSS repo for workload identity and make this work. The nightly build of Dapr would support this.

That being said - I just learned that the AKS workload identity extension will become generally available in 2 weeks and will include my fix, so at that point anyone can test workload identity in AKS using the Dapr nightly builds.

Officially workload identity in Dapr is not supported until the Dapr 1.11 release however.

[stuartleeks]

Thanks @berndverst - is there a guide to installing the Dapr nightly builds anywhere?

[manjitsinghh]

Is there any document to try out the workload identity in AKS using the Dapr.?