Even 2 User Identities both with the proper permissions (Read on Resource Group, Contributor to DNS Zone) causes this error.

I'm also getting this error when using AKS with managed identity auth enabled (which configures two other User assigned managed identities).

Is there a workaround until this is fixed?

I'm still getting this error, please is there a workaround for now?

As explained above, this issue occurred when more than 1 user assigned Managed Identity is associated with the Virtual Machine Scale Set. Adding a particular user assigned managed identity in the azure.json which is then used to create the secret resolved the issue for me.

{
"tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"resourceGroup": "resource-group-name",
"useManagedIdentityExtension": true,
"userAssignedIdentityID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

/remove-lifecycle stale

@digitamind I was following current azure guide and I am not sure how to get the userAssignedIdentityID. Where do we get this from?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

@darkn3rd if you have Azure AADPodIdentity setup in the cluster then you can use the following configuration to bind external-dns to the managed identity:

apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentity
metadata:
  name: my-external-dns
  namespace: kube-system
spec:
  type: 0
  resourceID: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-external-dns

  # az ad sp list --filter "displayName eq 'my-external-dns'" -o tsv --query '[].appId'
  clientID: 00000000-0000-0000-0000-000000000000
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentityBinding
metadata:
  name: my-external-dns-binding
  namespace: kube-system
spec:
  azureIdentity: my-external-dns
  selector: my-external-dns

And for the external-dns pod, add the following label: aadpodidbinding: my-external-dns.

/remove-lifecycle rotten

This also happens when using "useManagedIdentityExtension": true which means you are forced to not use this option and spin up your own user assigned identity and use that instead.

This issue needs resolving so that we can use the "useManagedIdentityExtension": true option

@njuettner,
Would it be possible to use this example to fix the problem?
https://github.com/Azure/aad-pod-identity/blob/master/test/image/identityvalidator/keyvault.go#L42-L48

In this issue here: Azure/aad-pod-identity#778 (comment) it was stated that the above code was used to solve this issue.
I wonder if the environment variable AZURE_CLIENT_ID is not getting set, and needs to be?

Hello all, any news on this issue? My customer is concerned by it.

@MCKLMT I do not have this this issue when using AAD Pod Identity. I have the default assigned managed identity, and one that I created, which grants access Azure DNS. I am using the preview feature to automate the process, just in case that makes things work.

As explained above, this issue occurred when more than 1 user assigned Managed Identity is associated with the Virtual Machine Scale Set. Adding a particular user assigned managed identity in the azure.json which is then used to create the secret resolved the issue for me.

{ "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "resourceGroup": "resource-group-name", "useManagedIdentityExtension": true, "userAssignedIdentityID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }

For those who are still struggling with, please follow @digitamind suggestion, thanks buddy, you saved my day!

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

@k8s-triage-robot: Closing this issue.

We are still having this issue. Any fixes or workaround on this?