Allow Azure Policy DeployIfNotExists actions on deployment stack managed resources with denyWriteAndDelete

[northynorth]

Is your feature request related to a problem? Please describe. Deployment stacks with denyWrite applied block the remediation of resources with Azure Policy and DeployIfNotExists actions. We use Azure Policy to deploy VM agents/extensions, VM applications, guest configurations, diagnostics and enforce other configurations to ensure resources comply with corporate standards. Defender for Cloud also heavily relies on Azure Policy for enrolling resources.

Describe the solution you'd like The simplest solution from an end user perspective I can think of is to allow managed identities to bypass the deny assignment in some way. Instead of just the 'All Principals' system defined principal perhaps there could be an 'All Users and Groups' one as well.

Describe alternatives you've considered Currently I am looking at creating a single user managed identity that could be used across all policy assignments and excluded from the deployment stack deny assignment. This would only use up one of the exemptions so would be workable, but it would need wide ranging permissions, probably contributor, probably tenant wide, which is not ideal.

Another option may be to add all Azure Policy assignment system managed identities to an Entra ID group and exclude this group object ID from the deny assignment. I'm not sure if this will work or not, and would be a bit less scalable as the policy assignment managed identity would need to be added to the exclusion group manually after the policy assignment is deployed.

[azcloudfarmer]

Hello @northynorth - in the example shared, did you add the policyAssignmentID as an excluded principal to the Deployment Stack mentioned?

[northynorth]

Hi @azcloudfarmer, we currently have 12 standard policy assignments with deployIfNotExits actions, each using it's own managed identity. Plus a number of VM applications deployed through policy, usually between 2 - 5 in a subscription depending on the requirements. This means we would need to exclude 15 or more identities on each stack deployment just for policy, plus we may want to exclude some admin identities in some cases. With a maximum limit of 5 exclusions this is not possible.

Even if there were more exclusions allowed this would mean that if we roll out a new deployIfNotExisits policy in the future we would need to manually update all the deployment stacks in scope with the new policy assignment identity.

[azcloudfarmer]

Hello @northynorth - thank you for the details above. On the Deployment Stacks side, a special bypass for Manage Identities on Deployment Stacks deny assignments does not make sense for us, given a Managed Identity can be used by many different resources (not just Azure Policy). We recommend exploring the option of grouping the identities in an Entra ID group as suggested and exclude the group object.