Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure provider no longer supports Sovereign clouds #3927

Closed
nbjohnson opened this issue Sep 11, 2023 · 9 comments · Fixed by #3942
Closed

Azure provider no longer supports Sovereign clouds #3927

nbjohnson opened this issue Sep 11, 2023 · 9 comments · Fixed by #3942
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@nbjohnson
Copy link

What happened:
When configuring the azure provider to use sovereign clouds, it always contacts the pubcloud management endpoint

What you expected to happen:
It should be reaching out to the cloud specific management endpoint

How to reproduce it (as minimally and precisely as possible):
Configure provider to be azure and cloud to be any sovereign cloud, it will always reach out to management.azure.com rather than the cloud specific management endpoint

Anything else we need to know?:
I think the issue was during the changeover to the new azure identity provider. The old code did a different call that directly included the specific environment's management endpoint:

zonesClient := privatedns.NewPrivateZonesClientWithBaseURI(cfg.Environment.ResourceManagerEndpoint, cfg.SubscriptionID)
The new code does not have any environment specific code that I can see:
zonesClient, err := privatedns.NewPrivateZonesClient(cfg.SubscriptionID, cred, nil)

According to the azure docs it looks like some sort of client option needs to be passed in:

You can use ClientOptions in package github.com/Azure/azure-sdk-for-go/sdk/azcore/arm to set endpoint to connect with public and sovereign clouds as well as Azure Stack. For more information, please see the documentation for azcore at [pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/azcore](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/azcore).

options := arm.ClientOptions {
    ClientOptions: azcore.ClientOptions {
        Cloud: cloud.AzureChina,
    },
}
clientFactory, err := armprivatedns.NewClientFactory(<subscription ID>, cred, &options)

Not sure if it can directly be passed in to the current client call or if a factory call is needed like in the example: https://github.com/Azure/azure-sdk-for-go/tree/main/sdk/resourcemanager/privatedns/armprivatedns#client-factory

Environment:

  • External-DNS version (use external-dns --version): 0.13.6
  • DNS provider: azure
  • Others:
    cloud: AZUREUSGOVERNMENTCLOUD
@nbjohnson nbjohnson added the kind/bug Categorizes issue or PR as related to a bug. label Sep 11, 2023
@nbjohnson
Copy link
Author

@phillebaba Sorry to ping you, but since you were the one to make the changeover to the new azure sdk in #3040, are you more familiar with how the new library should be configured to be able to call sovereign clouds?

@phillebaba
Copy link
Contributor

phillebaba commented Sep 14, 2023

I am currently on a biking trip so I don't have my computer with me. I won't be home for another 10 days. @miwithro you might be able to help with this?

@jbpaux
Copy link
Contributor

jbpaux commented Sep 15, 2023

I can have a look if needed :)

@nbjohnson
Copy link
Author

@jbpaux Any help would be greatly appreciated. From what I can see the identity request is properly having its cloud env set and doing the correct call, but it seems like the code change means that the actual resource call isnt getting the cloud env information and always sends the request to the public management endpoint rather than the env specific one. Docs werent the most clear on how to make sure the cloud env is being sent with the resource request

@jbpaux
Copy link
Contributor

jbpaux commented Sep 15, 2023

Yes after a quick review we can see the auth requests goes to the correct environment but all other requests are using default client options.
It seems we can either use a factory or update the 2 client creation to include the correct cloud information, let me have a look

@jbpaux
Copy link
Contributor

jbpaux commented Sep 15, 2023

if you want to give a try as I don't have any sovereign cloud access on this image docker hub image : jbpaux/external-dns:91cae9b1. I've built it with this commit 91cae9b

@nbjohnson
Copy link
Author

@jbpaux Thanks for taking a look at that. Is it an easy build process? Might be easiest for me to manually build the changes to test. But if I have time I can try to test on Monday to see if those changes solve my issue with the sovereign cloud env

@jbpaux
Copy link
Contributor

jbpaux commented Sep 15, 2023

you have build instructions in contributing doc if you want to build it yourself. Clone my repo and checkout the fix/azure-sovereign-clouds branch

@nbjohnson
Copy link
Author

@jbpaux These changes appear to have fixed my issue, it is now connecting to the env specific management endpoint. Thanks for proposing the changes, I cannot wait until they are merged in and in a release version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants