Workload Identity Login in Azure China is calling wrong resource principal (Azure Public)

[janpfischer]

Bug Report

Hello I am trying to use workload identities via external-dns. For the Azure Public cloud this is working without a problem. The Environment Variables are hooked and the pod is able to connect to Azure via Workload Identity.

External-dns is using azcore in version v1.7.0 and azidentity in version v1.3.0.

However, for Azure China this seems not to be working as expected. In my configuration I've set the Azure Cloud to AzureChina and the ENV is correctly hooked to the China Endpoint AZURE_AUTHORITY_HOST : https://login.chinacloudapi.cn/.

I've set the client-id and the tenant-id with annotations to the service-account and labeled the pod to use workload identities.

The azure sdk implementation then returns the following error:

POST https://login.chinacloudapi.cn/xxxxxx/oauth2/v2.0/token\n--------------------------------------------------------------------------------\n
RESPONSE 400 Bad Request\n--------------------------------------------------------------------------------\n
{\n  \"error\": \"invalid_resource\",\n  \"error_description\": \"AADSTS500011: The resource principal named https://management.core.windows.net/ was not found in the tenant named xxxx. 
This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
...

I've already took a look at Issues #20884 and #18508. Through #18508 I believe that instead of https://management.core.windows.net the URL should be https://management.core.chinacloudapi.cn.

I've found no way to configure that and I understood that this URL should be set automatically by the SDK.

Thank you very much. Every help is highly appreciated.

[chlowell]

The error indicates the credential is configured correctly because it sent the token request to the correct URL. The "resource principal" is specified by the client, whose configuration is independent of the credential's. Have you configured the client for Azure China? Code for that would look like this:

import (
	"github.com/Azure/azure-sdk-for-go/sdk/azcore/arm"
	"github.com/Azure/azure-sdk-for-go/sdk/azcore/cloud"
	"github.com/Azure/azure-sdk-for-go/sdk/azcore/policy"
	"github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/subscription/armsubscription"
)

opts := arm.ClientOptions{
	ClientOptions: policy.ClientOptions{
		Cloud: cloud.AzureChina,
	},
}
client, err := armsubscription.NewClient(todo, &opts)

(armsubscription is an arbitrary example; all ARM clients have the same API for this)

[github-actions]

Hi @janpfischer. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[janpfischer]

Thank you for your answer.
It should be set. I've passing the String AZURECHINACLOUD in my configuration which is then returned here to cloud.AzureChina and is then used here to create the ClientOptions object and finally used here for the workload identity.

I am also pretty sure that the lookup from AZURECHINACLOUD to cloud.AzureChina is working because if I pass a string which is not include in the case switch I've got the intended error message.

For me this looks good from configuration side.

[jbpaux]

It was a mistake in the implementation of external-dns which has been fixed in kubernetes-sigs/external-dns#3942 but it's not yet in a release. You'll have to use an image compiled from master.

[janpfischer]

Thank you very much, @jbpaux . I will test this and report back (just for the record if someone else will encounter same problems)

[janpfischer]

I can confirm that the fix in the current main branch of erxternal-dns is working and this problem is resolved.

For anyone who encounters this problem in the future: Make sure to use a release from external-dns which includes the Bugfix from kubernetes-sigs/external-dns#3942.

[chlowell]

Great, I'm glad this is resolved. Thank you for sharing the details here.