I'm currently running Azure Container Apps in Workload Profile environments and exposing them publicly via Azure Front Door. However, we're looking to avoid Private Endpoints due to their cost, as each one triggers a management fee of approximately $65 per month for each environment, which can get quite expensive with multiple apps.
The issue is that we want to restrict incoming traffic so that only our Azure Front Door instance can access the Container App's origin, but without using Private Endpoints, our options seem limited. Here are some challenges we've encountered:
- The current CAE ingress IP restrictions only accept IPv4 CIDR ranges and do not support service tags or header filtering. Since Azure Front Door's IPs are dynamic, maintaining a static list is not practical.
- Using an NSG with the AzureFrontDoor.Backend service tag doesn't appear to help, as inbound NSG rules may only apply to traffic through the VNet, potentially leaving the public CAE endpoint exposed.
- Although validating the X-Azure-FDID header in our app code could be a solution, we are using a third-party application that we cannot modify.
- App Service offers a feature that combines the AzureFrontDoor.Backend service tag with X-Azure-FDID header validation, which is convenient. Unfortunately, the Container Apps do not have a similar feature.
We are determined to stick with Workload Profile environments and avoid using Private Endpoints or modifying application code. Is there anything we might be missing, or does anyone have suggestions on how to achieve this?
4 Answers
If you're looking to work within these restrictions, setting up a sidecar container might be a solid option. You can use a lightweight container to handle the header validation on behalf of your third-party application.
We've faced this exact challenge while migrating our Container Apps workloads. It's definitely frustrating that Azure doesn’t provide a direct way to restrict traffic like App Service does. We resorted to using an NGINX sidecar to validate the X-Azure-FDID before allowing access to our main container. This way, you maintain control over the configuration without touching your third-party app code.
Here's a quick snippet of how we did it in the NGINX config:
```
if ($http_x_azure_fdid != "your-front-door-id") {
return 403;
}
```
The cost from Private Endpoints really adds up once you have more than a few environments. The NGINX sidecar is lightweight and cost-effective—only a few MB of memory. Just make sure to validate the specific Front Door ID and not just the presence of the header, as anyone could spoof it.
Here's a potential workaround: you could put a reverse proxy or Azure API Management in front of your Container App and whitelist its static IPs. This way, you'll have a better control over who can access it.
Wasn't the goal of the new workload profile environments to allow you to avoid dedicated consumption when using Private Endpoints? It sounds like there might be some confusion. If I remember correctly, enabling a Private Endpoint shouldn’t force a specific environment. You may want to check that again. As far as I know, Private Endpoints can support any profile type.
From the information I've read, Private Endpoints only run on premium SKUs of Azure Front Door. If that's your setup, there shouldn't be any additional costs.
Related Questions
How to Build a Custom GPT Journalist That Posts Directly to WordPress
Fix Not Being Able To Add New Categories With Intuitive Category Checklist For Wordpress
Get Real User IP Without Installing Cloudflare Apache Module
How to Get Total Line Count In Visual Studio 2013 Without Addons
Install and Configure PhpMyAdmin on Centos 7
How To Setup PostfixAdmin With Dovecot and Postfix Virtual Mailbox