Deny-PublicPaaSEndpoints contains both overlapping and non-working deny public network policy for Container Apps

[mysteq]

Describe the bug The initiative Deny-PublicPaaSEndpoints seems to currently have two overlapping policies for Container Apps.

It is: Container Apps environment should disable public network access https://www.azadvertizer.net/azpolicyadvertizer/d074ddf8-01a5-4b5e-a2b8-964aed452c0a.html

which enforces internal access only on the Container Apps Environment level, and then: Container Apps should disable external network access https://www.azadvertizer.net/azpolicyadvertizer/783ea2a8-b8fd-46be-896a-9ae79643a0b1.html

which enforces on the container apps level. However due to the first being enforced, the second one is moot, since you will not be able to have public network access on an Container Apps Environment that is set to internal only.

Also the "783ea2a8-b8fd-46be-896a-9ae79643a0b1" has a faulty logic, as it enforces you to put an Ingress on the Container Apps, which is not always needed, and a Container App without Ingress should also be fine as it does not give external access.

Steps to reproduce

1. Deploy an Container Apps Environment with a virtual network and enforced to internal.
2. Try to deploy a Container Apps without Ingress enabled, and it will be denied by the policy.

Screenshots

[mysteq]

Just to add for clarification, the use case would be i.e. running a Container in Container Apps Environment that only does outbound processing. Which is secure since no Ingress for inbound traffic is needed, however that is blocked by "Container Apps should disable external network access", because that policy enforces an Ingress. You can workaround that with adding an Ingress, but that also implies that you need to have an endpoint added for health checks I believe, to have a stable working container.

[Springstone]

@mysteq I'm no Container Apps expert, so I'm not sure how to proceed. As I understand it, the Container Apps policy is not needed as the Container Apps Environment policy will always apply and disallow public access.

Is the ask to remove the Container Apps policy from the initiative (and only keep the Container Apps Environment policy)?

Additionally, if there are issues with built-in policies, we advise to open a support ticket for the same as the ALZ team does not own/author those built-in policies.

[mysteq]

Yes, removing the Container Apps policy from the initiative would be my preferred ask.

I already have a separate support ticket for the Built-In policy, but if it's fine to remove the policy from the initiative, then that would solve all issues for us.

[mysteq]

Apparently there is no support ticket team that can review or do anything with built-in policies either, so I only got a pointer to the feedback site, so I gave up on that.

@Springstone As I see it, the Container Apps Environment itself solves the need for ALZ for denying public endpoints, and the other adds just unneeded complexity and does not give any value (and also is broken for running anything without ingress) and should therefor be removed.

[heintonny]

@mysteq I'm no Container Apps expert, so I'm not sure how to proceed. As I understand it, the Container Apps policy is not needed as the Container Apps Environment policy will always apply and disallow public access.

Is the ask to remove the Container Apps policy from the initiative (and only keep the Container Apps Environment policy)?

Additionally, if there are issues with built-in policies, we advise to open a support ticket for the same as the ALZ team does not own/author those built-in policies.

Thank you for raising this issue, @mysteq. Let me clarify the confusion around Container Apps policies:

The Container Apps policy in question relates to ingress configuration rather than public/private endpoint access:

• Internal ingress: Only allows connections between apps within the same Environment
• External ingress: Allows connections from outside the Environment (can use either public OR private endpoints)

This policy should be removed from the "Deny-PublicPaaSEndpoints" initiative because:

1. It incorrectly blocks external ingress with private endpoints
2. It doesn't align with the initiative's purpose of only blocking public endpoints

I also agree with @mysteq that a more logical approach would be a policy that allows internal ingress when needed, rather than enforcing it in all cases. Even then, it wouldn't belong in this initiative since the initiative should strictly focus on denying public endpoints.