Blog Post

Apps on Azure Blog
5 MIN READ

Azure Container Apps Virtual Network Integration

kendallroden's avatar
kendallroden
Icon for Microsoft rankMicrosoft
Feb 02, 2022

 

Azure Container Apps Virtual Network Integration release announcement

 

At Ignite, we announced Azure Container Apps, a serverless application-centric hosting service that enables users to quickly deploy containerized applications and microservices to Azure without the need to configure and manage underlying infrastructure resources or container orchestrators. Azure Container Apps runs on  Azure Kubernetes Service, and includes several open-source projects: Kubernetes Event Driven Autoscaling (KEDA)Distributed Application Runtime (Dapr), and Envoy. This open-source foundation enables teams to build and run portable applications powered by Kubernetes and open standards without the operational overhead and management complexity of working with the platform directly.

 

Since its preview release, the Azure Container Apps service has continued evolving to address customer needs and respond to customer feedback.  One point of focused investment has been addressing asks related to network isolation. For security and compliance reasons, many enterprise customers require isolation to ensure internal, mission critical applications are inaccessible from the public internet. In addition, customers typically have existing cloud resources like databases, queues, file shares, etc. that an application needs to integrate with over this internal, private network. Today, we are excited to announce that Azure Container Apps can be deployed into your custom Azure Virtual Network! In the remainder of this blog, we will walk through configuring inbound and outbound virtual network integration for an Azure Container Apps environment and subsequently deploying Container Apps to the running environment.

 

Configure Virtual Network for an Azure Container Apps Environment

 

To host your containerized applications using Azure Container Apps, you must first deploy an Azure Container Apps environment. The environment can host one or more applications and establishes the network boundary, meaning all applications within the shared environment are deployed to the same Azure virtual network.

 

As of today, you have the option to bring your own virtual network when creating a new Azure Container Apps environment. If you choose to do so, you will need to provide the network along with a designated subnet: the control plane subnet. The control plane subnet will be used to provide IP addresses from your internal network to the Azure Container Apps control plane infrastructure components as well as your application containers.

 

It is important to note that currently, the size of the subnet provided should be at least /23. This subnets should not overlap with the following reserved ranges:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

 

In addition to defining where the service will be deployed, you also have the option to configure inbound access: Internal or External.

 

External

If you choose to deploy an external Azure Container Apps environment, the environment will be accessible via a public endpoint. This endpoint is an Azure Public IP address. 

 

External Azure Container Apps Environment

 

Internal

If you would like to lock down your environment from the public internet, you can deploy an internal environment instead. The internal deployment will create an environment that only exposes applications via an IP address from within your virtual network. The list of traffic dependencies required can be found here: Securing a custom VNET in Azure Container Apps | Microsoft Docs.While UDR support is not available today, it is on our roadmap.

 

Internal Azure Container Apps Environment

 

Keep in mind, an internal environment will have public IPs, however they will be used solely for outbound connectivity.

 

Managed resources

 

When you deploy an internal or an external environment into your own network, you will see a new Resource Group with the “MC_” prefix created in the Azure subscription where your environment is hosted. This resource group contains infrastructure components managed by the Azure Container Apps platform. This resource group should not be modified. You will see Public IP addresses which are used specifically for outbound connectivity from your environment as well as an internal or external load balancer depending on your environment configuration. Because the load balancer is created in your subscription, there are additional costs associated with deploying the service to a custom virtual network.

 

Deploying Azure Container Apps Environment into a new virtual network

 

DNS Resolution for Internal Container Apps Environments

 

As mentioned in the previous section, an internal-only Azure Container Apps environment will receive an IP address directly from the network provided. By default, there is no domain registration for the internal load balancer (ILB) that is created. This means customers will be responsible for configuring DNS resolution for the environment endpoint. In Azure, this can be accomplished by creating and configuring an Azure Private DNS Zone.

 

After deploying the Container Apps environment into a virtual network, you can retrieve the static, internal IP and the default domain. To start hosting the domain in Azure DNS and creating DNS records, the first step is to create the Private DNS Zone. To publish the private DNS zone to your virtual network, you will need to provide a list of virtual networks that are allowed to resolve records within the zone. This list should include the network where your environment is deployed. Once you have created the network link, you can add a wildcard DNS record which will resolve traffic bound for the default domain to the IP address of the environment’s ILB. After completing these steps, your environment will be resolvable by other services in the list of linked networks using the default domain.

 

 

Creating and configuring a Private DNS Zone for your internal Azure Container Apps Environment

 

Deploying Container Apps to the Container Apps Environment

 

At this stage, you can begin deploying your application workloads to the deployed environment! The accessibility level you selected for the environment will impact the available ingress options for your container app deployments. Azure Container Apps provides HTTPS ingress with TLS termination as a built-in feature, so you do not need to deploy an Azure Load Balancer, Public IP address, or any other Azure resources to enable HTTPS ingress.

 

If you are deploying to an external environment, you have two options for configuring ingress traffic to your container app: Limited to Container Apps Environment or Accepting traffic from anywhere. You will allow traffic from anywhere if you want the application to be accessible from the public internet. Otherwise, you can choose to allow only traffic from other container apps deployed within the shared Container Apps environment.

 

External Environment App Ingress Configuration Options

 

 

If you are deploying to an internal environment, you also have two options for configuring ingress traffic to your container app: Limited to Container Apps Environment or Limited to VNet (Virtual Network). You will allow traffic from the VNet if you want your container app to be accessible from other Azure resources or applications within the virtual network or connected to the virtual network through Peering or some type of VPN connectivity. Otherwise, you can choose to allow only traffic from other container apps deployed within the shared Container Apps environment.

 

Internal Environment Container App Ingress Configuration Options

 

Next Steps

 

If you’re looking to learn more about Azure Container Apps and when to use it, check out the latest episode of Microsoft Mechanics. Jeff Hollan shares how the container apps platform plays a critical role in enabling modern applications in the cloud.

 

 

If you are interested in learning more about the VNet integration feature specifically, visit the Azure Container Apps custom virtual network Microsoft Docs. We encourage you to share your feedback via our GitHub microsoft/azure-container-apps repo, connect with us on discord and join our mailing list so we can continue enhancing your experience with Azure Container Apps!

 

Updated Sep 02, 2022
Version 3.0
  • Kris's avatar
    Kris
    Copper Contributor

    Will private endpoints within the VNet to other Azure services work?

    Can a VNet NAT Gateway be assigned to the container apps subnet for Internet egress?

  • evequefou's avatar
    evequefou
    Copper Contributor

    Is there a way to support non-HTTP ingress?  I have an HTTPS-only container to which I'd like to add gRPC support, but there doesn't appear to be an option for a port to reach the container directly.

  • AnthonyDiaz's avatar
    AnthonyDiaz
    Copper Contributor

    Is there any thought being done to not require the public IP for egress (specific to the internal-only Azure Container Apps environment)?  We're looking for a use case where this would be very useful but due to security requirements, any egress needs to route through our network in the cloud and not direct to the internet (to ensure DLP and other security stack is not circumvented). 

  • Pete_Neville's avatar
    Pete_Neville
    Copper Contributor

    Really helpful article - thank you. Setting up the DNS has enabled me to call the container app from my app service, which was not obvious and would have stumped my for some time.

    I hope the use of internalOnly environments via the cli is fixed soon.

  • hoangminhung's avatar
    hoangminhung
    Copper Contributor

    This command is incorret. 

    az containerapp env show -n $env_name -g $RG --query staticIp --out json

     

    it should be 

    az containerapp env show -n $env_name -g $RG --query properties.staticIp --out json
  • SeadS's avatar
    SeadS
    Copper Contributor

    hello,

    we are using custom dns servers configured in vnet, and these servers are our dns servers on prem but running on azure vm's.

    On these machines i have configured recomended forwarder on dns servers in azure, is there anyting else that needs to be prepared so resolving of azure container environment will work?

    we will check is the azure firewall and nsg blocking this traffic.

    If azure private dns zone is configured in custom vnet option, can this block custom dns resolution?

    Thank you for all your help 🙂

    BR: