Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 16 days ago.
Improve this question
I plan to use Azure Front Door in front of my Container App and allow access only through Front Door. I have deployed an Internal Container Apps environment with a custom virtual network. I have added an NSG to the infra-subnet with an Inbound Rule that allows Azure FrontDoor.Backend. But this doesn't seem to work.
Any suggestions on how to use Azure Front Door with Azure Container Apps?
Azure Front Door is CDN service that delivers high performance, scalability applications. It has customizable rules engine for advanced routing capabilities, we can add Azure Container App URL / load balancers IP's [[if it integrates with NSG allow respective ports in inbound]. Below sample example helps to deploy container app into Front Door.
Create and browse the container app URL, whether it was up and running or not without front door, either the way via Container App URL / Load Balancer.
Configure Front Door on container App
NOTE: Origin type will be custom if we use Container App URL.
Click on Origin group and then verify whether its points to correct Endpoint or not ?
Copy the Front Door URL from Front Door Service
Output
To deploy AFD (Azure Front Door) with a private ACA (Azure Container Apps) environment you need to create a private link connection between Front Door and the internal Azure Load Balancer, that has been created by ACA.
For that reason you have to create a Private Link Service for the Load balancer.
The challenge is now to 'find' the Load Balancer the Private Link Service should be created for and add the ID of the Load Balancer to the Private Link Service resource, if done programmatically.
In my example I have used the default domain of the environment to create the name of the 'auto-generated' resource group, because you need to provide the name and the resource group of the Load Balancer to get the required ID.
Bicep example code:
// Create Container Apps Environment
resource environment 'Microsoft.App/managedEnvironments#2022-03-01' = {
name: environmentName
location: location
...
}
// Get the Default Domain of the ACA environment
var containerAppsEnvironmentDefaultDomain string = environment.properties.defaultDomain
// Split the domain to get the identifier of the ACA environment (the element before the location)
var containerAppsNameIdentifier = split(containerAppsDefaultDomainName, '.')[lastIndexOf(containerAppsDefaultDomainArray, location)-1]
// Use the identifier to 'generate' the resource group name
var containerAppsManagedResourceGroup = 'MC_${containerAppsNameIdentifier}-rg_${containerAppsNameIdentifier}_${location}'
// Get the ID of the Load Balancer
resource loadBalancer 'Microsoft.Network/loadBalancers#2021-05-01' existing = {
name: 'kubernetes-internal'
scope: resourceGroup(containerAppsManagedResourceGroup)
}
The full example including all Bicep code can be found at Github:
https://github.com/sebafo/frontdoor-container-apps
Related
We have a React app hosted in a storage account (with static website enabled). We have a Azure Front door in front of the storage account.
We are looking at ways to limit access to the storage account, to ensure that only the Azure Front Door could read from it.
We put the storage account in a VNet and tried setting up a private link to allow Azure Front Door access to it. But when setting up the Azure FD profile, we get an error saying The origin type or host name does not support private link.
Is there a way to secure the storage account in a VNet and allow Azure FD access to it? Or is there a better way to secure this?
• Yes, you surely can secure the connection from the Azure Front door to the storage account deployed in a virtual network, to be specific, to a static website hosted in it. For that purpose, you will have to deploy an Azure front door in classic tier and configure the frontend domain hostname as ‘xyzfd.azurefd.net’ and the backend pool hostname target as FQDN ‘storageaccountname.z29.web.core.windows.net’ as shown below as well as enable the routing rules for this configuration by selecting the accepted protocol and the frontend domain for this routing request: -
Once done, ensure to create a DNS zone and create the requisite ‘A’ host DNS records in it pertaining to the custom domain that is registered as the frontend domain/hostname in the Azure front door and similarly create a CNAME record for the same hostname/domain name with the alias being the static website primary endpoint as shown above.
• This will ensure that secure access to the static website is configured through the DNS records registered as above and are accessible through them.
For more information, kindly refer to the below links: -
https://docs.rackspace.com/blog/Azure-Front-Door-Storage-Static-Website/
I'm trying to secure my containerized web app with a Premium V2 App Service Plan. I've enabled Service Endpoints for an integration subnet for the different App Services to restrict incoming traffic from each other except for the frontend (so all of them are integrated with the VNet and all have incoming traffic restricted to that VNet except for the frontend).
I have also other Azure services like Azure Functions or a Storage Account that can have inbound traffic restricted by using those Service Endpoints. However, One of the App Services calls an external 3rd party API that lies on Azure too. That API may or not be behind a static IP. However, it has a Custom Domain associated.
The problem arises when I try to connect to that API from one of the VNet integrated App Services. As the destination IP is inside one of the IP ranges that are added to the routing with the use of a Service Endpoint, traffic is sent via that Service Endpoint instead of simple Azure routing. I've tried overriding the route with a Route Table associated to that subnet but that seems not to be possible, with or without a NAT Gateway attached to the subnet. I guess Azure routing is prioritized here. I'm sure the route is not effective as I used it on a different subnet where I deployed a VM.
Is there any way I can use that Service Endpoint for my internal traffic only so it's not used when it goes to an Azure hosted API or I need to switch to a different approach like Private Endpoints or an ASE?
I am unsure what you're looking for but if you want to explicitly define routes you should try using app services setting "WEBSITE_VNET_ROUTE_ALL" = 1 which overrides the default precedence of routing and makes sure that every outbound call follows the route defined inside route table of subnet.
Use the following steps to add the WEBSITE_VNET_ROUTE_ALL setting in your app:
Go to the Configuration UI in your app portal. Select New application setting.
Enter WEBSITE_VNET_ROUTE_ALL in the Name box, and enter 1 in the Value box.
When WEBSITE_VNET_ROUTE_ALL is set to 1, outbound traffic is still sent from the addresses that are listed in your app properties, unless you provide routes that direct the traffic elsewhere.
We've been able to ask the 3rd party to disable blocking rules. It turns out they had a rule that blocked this specific traffic.
I already tried changing that setting, but didn't try putting a route table on it. However, it'd make no difference as I can't define a list of allowed outbound IPs belonging to Azure since we have no static IP to call.
I have an azure app service which enabled custom domain as "www.mysite.com", we would like to set up a web application firewall on front door to protect slow read http attack.
After setting up Azure Front Door, my front end host is shown as "mysite.azurefd.net", and the issue of slow read http attack was gone, which is perfect!
But the new problem is, we want to custom front end host to "www.mysite.com" which eventually forwards/redirects to app service with the same domain name, not the default "mysite.azurefd.net". Because i always want user goes through front door to delivery request to my Azure app service
Is this doable?
But the new problem is, we want to custom front end host to
"www.mysite.com" which eventually forwards/redirects to app service
with the same domain name, not the default "mysite.azurefd.net".
You can add a custom name to your Azure front door frontend host name but you can not add the same domain name as the custom domain in your app service as A CNAME record is not allowed to coexist with any other data from RFC1912 section 2.4
In this case, you have to add a different domain like sub.mysite.com as the frontend host to your Azure front door like this, then add or update an existing routing rule that map frontend hosts sub.mysite.com with your path like /* to your existing backend pool of web app.
I'm struggling with how to use Azure API management together with App Service Environment v1 (aka ASEv1), i.e. how to set the things via Azure portal.
I have ASE with one app service (target is several of them) and I have APIM gateway pointing to the public host name of the service.
What I have to do to make the app services in ASE VNet to be accessible only through the APIM gateway, to keep the back-end services hidden?
I need to be able to manage APIM from Azure portal and to be able to access the services directly via FTPS for deployment, collecting logs, etc.
--
I've created a new subnet for the APIM and put it in the ASE VNet , where already ASE subnet was. Now I probably have to set some NSG rules but I'm not sure how and if it is all I'm supposed to do.
The second thing I'm not sure is how to change the APIM API settings. It now points to a public URL of the service - I do not know if it will be available after NSG changes.
There are a couple of options, depending on what you really want. If you're fine having your backend services visible by outside but not callable, you can employ any means of authentication between APIM and backend services:
Shared secret - header/query param
Client certificate authentication
IP filtering on the side of backend services
If you want to really hide backend services from outside, you'll have to put APIM and ASE into same VNET.
Following seems to work, although it may need some fine tuning.
In short, each layer put into separate external VNet with own Network Security Group (NSG), using caller's public IP address to manage access to VNet:
back-end service web app in ASEv1 VNet "vnet-ase", with associated NSG "nsg-ase"
APIM gateway put to a separate VNET "vnet-apim", with associated NSG "nsg-apim"
in nsg-ase allow access from public IP of APIM GW, to vnet-ase
nsg-apim will be used to manage connections to the APIM gateway
I am trying to experiment a little bit the different configuration possibilities in Azure and I am stuck trying to correctly configure SSL custom domains when using more than one Web Site (App Service) behind a Traffic Manager.
Without problem, I was able to:
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net )
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net ) behind a Traffic Manager ( subdomain.trafficmanager.net) (addressed here)
But when I try to add a second App Service behind the Traffic Manager, I get the following issues:
1. Cannot attach my custom domain ( subdomain.mydomain.com ) to the second App Service ( subdomain2.azurewebsites.net ). Error message is:
Failed to update hostname bindings:
The host name subdomain.mydomain.com is already assigned to another Azure website: subdomain1.
I don't understand how SSL will work with the second website if I can't add subdomain.mydomain.com in the list of domains it listens to (and in fact, it doesn't if you don't add it).
2. Cannot add the second App Service to the Traffic Manager's list of endpoints. Error message is:
Failed to save configuration changes to Traffic Manager profile 'mytrafficmanager'.
Error: Some of the provided Azure Website endpoints are not valid: One or more conflicts detected in traffic manager configuration. Multiple domains point to region "West Europe": subdomain1.azurewebsites.net, subdomain2.azurewebsites.net
But when I read the documentation it does seem possible to add more than one endpoint in the same region:
If your profile contains multiple endpoints in the same Azure region, then traffic directed to that region is distributed evenly across the available endpoints (based on the configured endpoint enabled/disabled status and the ongoing endpoint monitoring). If you prefer a different traffic distribution within a region, this can be achieved using nested Traffic Manager profiles.
The example using Traffic Manager and App Service on MSDN's documentation only shows how to do it with one App Service.
Am I doing anything wrong? If yes, what is the right way to add several websites/App Services behind a traffic manager in Azure?
Traffic Manager does support multiple endpoints in the same region. The challenge is that the App Service has restrictions on multiple Apps in the same region sharing the same custom domain. This impacts on Traffic Manager, since the Traffic Manager profile DNS name is automatically added as a custom domain in your apps when adding them to Traffic Manager.
We are in the process of publishing new documentation that covers this exact scenario. Pasting the new text below:
Can I use Traffic Manager with more than one web apps in the same region?
Typically, Traffic Manager is used to direct traffic to applications deployed in different regions. However, it can also be used where an application has more than one deployment in the same region.
In the case of Web Apps, the Traffic Manager ‘Azure Endpoints’ type does not permit more than one Web App endpoint from the same Azure region to be added to Traffic Manager. The following steps provide a workaround to this constraint:
Check that your Web Apps within the same region are in different web app 'scale units', i.e. different instances of the Web App service. To do this, check the DNS path for the <...>.azurewebsites.net DNS entry, the scale unit will look something like ‘waws-prod-xyz-123.vip.azurewebsites.net’. A given domain name must map to a single site in a given scale unit, and for this reason two Web Apps in the same scale unit cannot share a Traffic Manager profile.
Assuming each Web App is in a different scale unit, add your vanity domain name as a custom hostname to each Web App. This requires all Web Apps to belong to the same subscription.
Add one (and only one) Web App endpoint as you normally would to your Traffic Manager profile, as an Azure Endpoint.
Add each additional Web App endpoint to your Traffic Manager profile as an External Endpoint. This requires you to use the ARM experience for Traffic Manager, not ASM.
Create a DNS CNAME record from your vanity domain (as used in step 2 above) to your Traffic Manager profile DNS name (<…>.trafficmanager.net).
Access your site via the vanity domain name, not the Traffic Manager profile DNS name.
Regards,
Jonathan Tuliani, Program Manager, Azure Traffic Manager
Jonathan,
This issue is still confusing when integrating SSL.. I'm not trying to add instances to the same region, but diff regions.
https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#traffic-manager-example
This article does a good job of explaining the routing, but minus the SSL..
From the image. Say this is my configuration.. I have a *.contoso.com wildcard SSL. Of the 3 endpoints, contoso-us, contoso-eu, contoso-asia - which one do I install the SSL? Preferably all 3, but I can't set the all to use the custom domain and the SSL..
What am I missing here?