search

Azure / Enterprise-Scale

The Azure Landing Zones (Enterprise-Scale) architecture provides prescriptive guidance coupled with Azure best practices, and it follows design principles across the critical design areas for organizations to define their Azure architecture
https://aka.ms/alz
MIT License
1.72k stars 980 forks source link

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

Open mysteq opened 2 months ago

mysteq commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 4 weeks ago

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.