Container app traffic restriction

Question

Container app traffic restriction

Diana C 0

In trying to strengthen the security on a resource group (containing app services, container apps and other resources) I tried to further secure the container apps with a network security group. However, it seems like this is no longer possible as the container apps are already up and running, and we would have needed to create a vnet when creating them, which was not the case. Alright. So I tried to go the route of restricting which IPs are allowed to access each container app. The only place I found this configuration was on the Ingress tab, where I selected "Allow traffic from IPs configured below, deny all other traffic". While this worked fine on the ingress endpoint (my-app-container--a1b2c3.[...].azurecontainerapps.io), it did not work on the custom domain defined for the container app (app-container-readable-name.com), where I get RBAC: access denied error. Plus there is the risk that the next deploy will change the suffix on the endpoint with the next replica name.

Do I need to whitelist certain IPs from Microsoft in order for the custom domain translation to happen? Or is there another setting I must change? Or another place where to restrict the incoming traffic?

Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-07T11:30:13.39+00:00
@Diana C ,

Thanks for reaching out. To better understand and troubleshoot the RBAC: access denied issue on your custom domain (app-container-readable-name.com), could you please clarify the following:

If authentication is enabled on the container app, are you seeing the RBAC error before the authentication challenge or after successfully authenticating?

Are you trying to completely restrict access to specific IPs, or do you want to allow public access while enforcing authentication and RBAC controls?

Have you tested accessing the application via the custom domain from an allowed IP? If so, do you still encounter the RBAC error?
Diana C 0 Reputation points

2025-03-07T11:38:28.8433333+00:00
Hi Khadeer,

Thanks for the reply.

There is no authentication enabled on the container app, which is why the RBAC message thew us off. The custom domain is always accessible from the outside.

We are trying to allow access only from specific resources, namely other app services in the same resource group, so for instance only a website (app service) should be able to access the api container app. Therefore we first tried accomplishing this with a NSG and eventually settled on restricting by IP.

Yes, when the IP rules were in place, we tried accessing the application by custom domain (did not work - RBAC error) as well as full name with ingress specification (worked - accessible as it was before we added IP rules)from a whitelisted IP
Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-07T12:54:29.2033333+00:00
@Diana C ,

Microsoft dynamically updates the list of outbound IP addresses used by Azure services . Whitelisting these regional service IPs in the IP restriction settings could resolve the issue. However, there are a few considerations:

Microsoft updates these IP ranges weekly,the allowlist will need to be updated frequently.

The latest IP ranges can be obtained from Microsoft’s official source: Azure Datacenter IP Ranges Meanwhile I am checking with internal team on any other alternate apporaches
Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-11T13:51:32.2366667+00:00
@Diana C ,

Thank you for your response. Based on our discussions and feedback from the Container Apps team, I would like to suggest the following approaches to address your requirements:

Using Private Endpoints with Azure Front Door (Recommended Approach)

By enabling Private Endpoints for the container apps, you can eliminate all external access.

When combined with Azure Front Door (AFD), only your chosen inbound domain (registered via AFD) will be able to access the app.

This approach ensures a secure, controlled entry point while keeping your resources private.

To enable communication between your App Services and the Container App, you can:

Place both services in the same VNet and configure networking to route traffic through the same private endpoint.

Alternatively, you can set up separate private endpoints for different applications based on your access control needs.

This should effectively restrict access to only the desired resources within the VNet while preventing unwanted external traffic.

Alternative Approach: Whitelisting Microsoft Regional Service IPs as suggested earlier.
Diana C 0 Reputation points

2025-03-11T13:53:28.4+00:00

Hi Khadeer,

Thank you for the reply. Is it possible to place container apps in a VNET after they were created? It was my understanding that, unless this happened on creation, it couldn't be achieved later.
Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-11T14:05:13.38+00:00

@Diana C ,

Your understanding is correct! Container Apps must be placed in a VNet at the time of creation, and currently, Azure does not support moving an existing Container App into a VNet after deployment.

1 answer

Your answer

Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-07T11:30:13.39+00:00

@Diana C ,

Thanks for reaching out. To better understand and troubleshoot the RBAC: access denied issue on your custom domain (app-container-readable-name.com), could you please clarify the following:

If authentication is enabled on the container app, are you seeing the RBAC error before the authentication challenge or after successfully authenticating?

Are you trying to completely restrict access to specific IPs, or do you want to allow public access while enforcing authentication and RBAC controls?

Have you tested accessing the application via the custom domain from an allowed IP? If so, do you still encounter the RBAC error?
Diana C 0 Reputation points

2025-03-07T11:38:28.8433333+00:00

Hi Khadeer,

Thanks for the reply.

There is no authentication enabled on the container app, which is why the RBAC message thew us off. The custom domain is always accessible from the outside.

We are trying to allow access only from specific resources, namely other app services in the same resource group, so for instance only a website (app service) should be able to access the api container app. Therefore we first tried accomplishing this with a NSG and eventually settled on restricting by IP.

Yes, when the IP rules were in place, we tried accessing the application by custom domain (did not work - RBAC error) as well as full name with ingress specification (worked - accessible as it was before we added IP rules)from a whitelisted IP
Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-07T12:54:29.2033333+00:00

@Diana C ,

Microsoft dynamically updates the list of outbound IP addresses used by Azure services . Whitelisting these regional service IPs in the IP restriction settings could resolve the issue. However, there are a few considerations:

Microsoft updates these IP ranges weekly,the allowlist will need to be updated frequently.

The latest IP ranges can be obtained from Microsoft’s official source: Azure Datacenter IP Ranges Meanwhile I am checking with internal team on any other alternate apporaches
Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-11T13:51:32.2366667+00:00

@Diana C ,

Thank you for your response. Based on our discussions and feedback from the Container Apps team, I would like to suggest the following approaches to address your requirements:

Using Private Endpoints with Azure Front Door (Recommended Approach)

By enabling Private Endpoints for the container apps, you can eliminate all external access.

When combined with Azure Front Door (AFD), only your chosen inbound domain (registered via AFD) will be able to access the app.

This approach ensures a secure, controlled entry point while keeping your resources private.

To enable communication between your App Services and the Container App, you can:

Place both services in the same VNet and configure networking to route traffic through the same private endpoint.

Alternatively, you can set up separate private endpoints for different applications based on your access control needs.

This should effectively restrict access to only the desired resources within the VNet while preventing unwanted external traffic.

Alternative Approach: Whitelisting Microsoft Regional Service IPs as suggested earlier.
Diana C 0 Reputation points

2025-03-11T13:53:28.4+00:00

Hi Khadeer,

Thank you for the reply. Is it possible to place container apps in a VNET after they were created? It was my understanding that, unless this happened on creation, it couldn't be achieved later.
Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-11T14:05:13.38+00:00

@Diana C ,

Your understanding is correct! Container Apps must be placed in a VNet at the time of creation, and currently, Azure does not support moving an existing Container App into a VNet after deployment.

Answer 1

@Diana C ,

Based on our discussions and feedback from the Container Apps team, summarizing the possible ways

Using Private Endpoints with Azure Front Door (Recommended Approach)

Enabling Private Endpoints for your Container Apps eliminates all external access.
When combined with Azure Front Door (AFD), only requests from your registered inbound domain (via AFD) will be allowed.
This approach ensures a secure, controlled entry point while keeping your resources private.

To enable communication between your App Services and Container App, you can:

Place both services in the same VNet and configure networking to route traffic through the same private endpoint.
Alternatively, set up separate private endpoints for different applications based on your access control needs.
This will effectively restrict access to only the required resources within the VNet while preventing unwanted external traffic.

But as you have mentioned Container Apps must be placed in a VNet at the time of creation, and currently, Azure does not support moving an existing Container App into a VNet after deployment.

Alternative Approach: Whitelisting Microsoft Regional Service IPs

If transitioning to Private Endpoints is not feasible, another option is to whitelist Microsoft’s regional service IP ranges in the IP restriction settings. However, there are some considerations:

Microsoft updates these IP ranges weekly, requiring frequent allowlist updates.
The latest IP ranges can be obtained from Azure Datacenter IP Ranges.

Khadeer Ali 3,830 Reputation points Microsoft External Staff

2025-03-13T12:46:31.06+00:00

@Diana C ,

Following up to check if there is anything else I can assist you with.

Share via

Container app traffic restriction

1 answer

Your answer