Repository navigation
Is it possible to put Azure App Configuration behind Azure Front Door? #567
Description
Activity
- changed the title
[-]Is it possible to put Azure Front Door in front of Azure App Configuration?[/-][+]Is it possible to put Azure App Configuration behind Azure Front Door?[/+]on Oct 21, 2021 Hello David Peden (@david-peden-q2) ,
The issue is because the App Configuration SDK uses the endpoint of the target app configuration instance when it acquires an authentication token for authenticating requests. In this case it looks like you are setting up your client so that the endpoint is pointing to Azure Front Door. When the client tries to get a token it fails because the Azure Front Door endpoint isn't a valid value for getting an authentication token.
This scenario is not something that is going to work cleanly out of the box right now. It would need a bit of customization on your end to get it working today.
May I ask what type of Azure Credential you are using to set up your client? For example, DefaultAzureCredential.
david-peden-q2 commented
on Oct 28, 2021 AuthorMore actionsHey Jimmy Campbell (@jimmyca15), thanks for the response. I have an open dialog going with Azure Support at the moment and am awaiting their response.
In the meantime, if you know of a way to get this working, that would be awesome.
I agree with your assessment. I am using
DefaultAzureCredential. I have also added my (verified) custom domain to our tenant. I have even tried creating an app registration who's app uri points to the verified domain. None of this has changed the error I get from the client.Is there a way to create a custom HTTP pipeline that will enable this to work? I’ve pulled down the code from https://github.com/Azure/azure-sdk-for-net and have been reviewing the Azure.Data.AppConfiguration, Azure.Identity, and Azure.Core solutions but I haven’t successfully pieced anything together yet.
It seems like https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/appconfiguration/Azure.Data.AppConfiguration/src/ConfigurationClient.cs#L83 may be the clue to the solution I'm looking for.
Edit: having said all that, since I have Front Door strictly set up for request forwarding, I'm not sure why the request doesn't make it to a config service endpoint for token acquisition unless the client terminates early by inspecting the uri of the request (to verify that the endpoint ends in *.azconfig.io) before actually sending it.
A clean solution for this scenario is going to require changes on our side and after having looked at this we have already started working on them. Until this work is finished on our side, any solution is going to be a workaround at best and I wouldn't consider it production ready. I'll provide some details on your questions though.
Edit: having said all that, since I have Front Door strictly set up for request forwarding, I'm not sure why the request doesn't make it to a config service endpoint for token acquisition unless the client terminates early by inspecting the uri of the request (to verify that the endpoint ends in *.azconfig.io) before actually sending it.
The reason that the request does not make it to your front door instance is because before any request is sent to App Configuration (or in your case, to Azure Front Door) a request is first made to AAD. This request to AAD tries to get an AAD token to authenticate with Azure App Configuration. The token request uses the URI of the App Configuration instance as a parameter. However, in your case you are passing the URI of Azure Front Door to the App Configuration client, and the token request is using your Azure Front Door URI. AAD is considering this an invalid parameter and is throwing the error that you mentioned. This is happening all before the client makes a request to App Configuration.
Is there a way to create a custom HTTP pipeline that will enable this to work? I’ve pulled down the code from https://github.com/Azure/azure-sdk-for-net and have been reviewing the Azure.Data.AppConfiguration, Azure.Identity, and Azure.Core solutions but I haven’t successfully pieced anything together yet.
It's more of a problem with the parameters being passed to
TokenCredential. If you extendDefaultAzureCredentialoverrideDefaultAzureCredential.GetTokenAsyncyou will see the incorrect AAD scope parameter I mentioned above inTokenRequestContext.Scopes. A correct scope for App Configuration would use one of our documented AAD audiences.E.g.
Invalid App Configuration scope: "https://myfrontdoor.azure.com/.default"
Valid App Configuration scope: "https://*.azconfig.io"However, pitfalls can occur even if overriding the invalid scope to the valid scope that I mentioned. And this is something that needs to be addressed on our side.
- addedbugSomething isn't workingSomething isn't workingserviceIssues related to the AppConfig serviceIssues related to the AppConfig service
on Nov 4, 2021 - removedserviceIssues related to the AppConfig serviceIssues related to the AppConfig service
on Nov 7, 2021 Jimmy Campbell (@jimmyca15) thanks for the detailed response. I no longer have access to the email that I originally posted under so didn't see your response until now. thank you for your help.
Jimmy Campbell (@jimmyca15) has this issue been addressed?
Were you able to come to a working solution, or are you still seeking guidance on this issue?
Jimmy Campbell (@jimmyca15) Are there still plans on your side to address this use case of allowing Azure App Configuration to be put behind Azure Front Door?
Were you able to come to a working solution, or are you still seeking guidance on this issue?
hey Jimmy Campbell (@jimmyca15) i'm no longer working on the effort that originally triggered this question. having said that, i still think it would be a valuable addition. i am likely to start a new endeavor soon where i would be interested in this capability. as mwmardis asked, i would also like to know the official stance on this topic. thanks!
mwmardis David Peden (@davidpeden3)
There was a blocker that prevented this scenario when the original issue was filed. Now it should be good to go. The change that we made is that we started supporting the following AAD token audience:
https://azconfig.io.Now the following suggestion I gave in an earlier comment no longer has any blockers and should be able to be used to make this scenario work.
If you extend DefaultAzureCredential override DefaultAzureCredential.GetTokenAsync you will see the incorrect AAD scope parameter I mentioned above in TokenRequestContext.Scopes. A correct scope for App Configuration would use one of our documented AAD audiences.
In the case of the original comment, the scope would have been
"https://config.[redacted].com/.default", as extracted from the client's endpoint, whereas it should be the App Configuration scope like"https://azconfig.io/.default"Let me know if that needs any more clarification.
Also, do you mind sharing some of the motivation behind a setup like this? Is it for perceived availability increase for example?
- addedenhancementNew feature or requestNew feature or requestserviceIssues related to the AppConfig serviceIssues related to the AppConfig serviceand removedbugSomething isn't workingSomething isn't working
on May 12, 2022 The idea is to emulate (replicate?) the redundancy automatically provided by Azure Key Vault. When using ACS backed by AKV, it makes no sense not to have redundant ACS instances. Instead of relying on a chain of configured instances, relying on a pool fronted by Azure Front Door means that all clients get nearest/best ACS rather than all going to the configured instances in a fall-through scenario. Why ACS doesn't offer the same guarantee of redundancy as AKV feels like an oversight.
Since the discussion here, App Configuration has released geo-replication support with General Availability. This enables failover scenarios to ensure availability in case of regional outage. Additionally, the design of App Configuration's geo-replication allows you to take advantage of your replicas even if there is no disaster ongoing since the endpoints of all replicas are functionally equivalent.
To get started using geo-replication this how-to article can be referenced.
Reacted by Zhenlan Wang
I have set up three resource groups, each with their own instance of App Configuration. All keys/values are synchronized between the configuration stores. I have also created an Azure Front Door instance and associated frontend, backendpool, and route linking the frontend and backendpool via forwarding. Everything is wired up successfully. However, when I attempt to call into the front door config endpoint, I get an authentication failure in my app config client.
Calling the uri of any/all of the individual config services (backends) works fine.