Unable to attach a VNET to Container App environment after the env was created

[RajakumaranC]

Please provide us with the following information:

This issue is a: (mark with an x)

• bug report -> please search issues before submitting -- no similar issue found.
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Issue description

A clear and concise description of the observed issue.
I have created a container app environment without a VNET then tried to attach a VNET to existing container app environment. However, there are no CLI command nor portal option to do this, so I followed the steps for ARM template and populated the arm template with the VNET configuration with incremental build. Now this ARM template says it successfully deployed however, I still don't see the VNET getting attached to the Container App environment. Please help understand if we can add a VNET to a container App env after it was created without it. and should the arm throw error if it's not allowed.

Steps to reproduce

1. Create an env either via cli or portal without a VNET.
2. Create a vent with the required subnet CIDR.
3. export the template of the ACA env and modify the Infra subnet settings and populate with the Subnet Id.
4. Deploy the arm template via cli using az deployment group create --resource-group <RGNAME> --template-file .\<file>.json

Expected behavior [What you expected to happen.]
VNET should be attached to the container app environment

Actual behavior [What actually happened.]
ARM template says succeeded but VNET config is not updated in ACA env.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context

Ex. Did this issue occur in the CLI or the Portal?
CLI

[torosent]

Hi, You cannot attach a VNet after the environment is created but it's in our backlog to enable it.

[RajakumaranC]

@torosent : Thanks for looking into this issue. This feature will surely be helpful for many customers. For eg. We have a key vault that is only allowed to be accessed by specific IP range for security reasons. We found that key vault can be provided access via VNET instead of relying on the dynamic outbound IP of the ACA. (Static IP of ACA Env doesn't seems to work when accessing key vault). Hence this feature will be really helpful for customers that need to give access to firewall protected resource within Azure to gain secure access instead of relying on workload profile + NAT gateway.

Also ARM template is showing the deployment succeeded although this feature is not yet available. Should the ARM be throwing error until this feature is out?

[ffroliva]

I am experiencing this problem right now. I have added a container to a containerapp environment without vnet. Currently, the application is wide open to the internet. Now I want to make it private to a VPN but because I don't have the ability to update the VNET configuration I have to recreate the whole setup again.

This is a very important feature to be added.

Is it possible to update containerapp environment to add or replace a VNET using ARM template?

[Dikarabo-Molele]

Hi, You cannot attach a VNet after the environment is created but it's in our backlog to enable it.

Has this been enabled yet?

[bchr02]

Hi, You cannot attach a VNet after the environment is created but it's in our backlog to enable it.

Any update or ETA? Also, why do we have the "wontfix" label on this Github Issue if it is on the backlog? 😒

[eskye]

This feature will be a major game changer for customers. I have to go and recreate the container right now and attach it to the environment with VNET. @Azure team please do something about this quickly this is one of the major functionality when it comes to security and connecting to other resources on prem and it is very important and a must to have feature. We'll be expecting when this will be done.

Thank you for your support.

[ffroliva]

I agree. I struggled configuring my container environment because this feature doesn't exist. I suspect there is a major complexity behind this.

…

On Sun, 2 Jun 2024, 14:42 Sunkanmi Ijatuyi, ***@***.***> wrote: This feature will be a major game changer for customers. I have to go and recreate the container right now and attach it to the environment with VNET. @Azure <https://github.com/Azure> team please do something about this quickly this is one of the major functionality when it comes to security and connecting to other resources on prem and it is very important and a must to have feature. We'll be expecting when this will be done. Thank you for your support. — Reply to this email directly, view it on GitHub <#851 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF67VG6I5FBD3L5GPRBNX3DZFMON5AVCNFSM6AAAAAA2V4BLLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTHA2TSMJWHA> . You are receiving this because you commented.Message ID: ***@***.***>

[VashBik]

Upvoting this issue as this feature would be extremely beneficial for many scenarios where securing connections to internal resources is critical. Has there been any progress or an estimated timeline for when attaching a VNet post-creation might be supported?

[ejohnsson6]

How on earth is this a wontfix? At least the deployment shouldn't succeed if the changes to the configuration aren't propagated.