[Policy]: Enforce the presence of mandatory tags provided via parameter

[cjasset]

Policy Definition or Initiative

Definition

Built-in/Custom

Custom

Built-in policy definition or initiative ID

Custom policy definition or initiative description

A policy that audits for the presence of mandatory tags on resource groups and resources. Customer can input an array of tags and the policy will audit to ensure those tags are present and not null.

Scope

Intermediate Root

Default Assignment

• Yes

Comments/thoughts

Obviously there are already more complex tagging policies that can look for specific values etc but I have found for customers just getting started are not interested in updating or writing custom policies. A simple policy where they can input an array of mandatory tags is a good starting point. Later as they refine their environment they can iterate on this strategy. Here is an example policy I put together for a few of my customers which validates mandatory tags on resource groups.

mandatorytagspolicy.txt

[Springstone]

@cjasset thanks for posting this issue.
This is technically possible with built-in policies https://www.azadvertizer.net/azpolicyadvertizer/871b6d14-10aa-478d-b590-94f262ecfa99.html and https://www.azadvertizer.net/azpolicyadvertizer/96670d01-0a4d-4649-9c89-2d3abc0a5025.html

You can create an initiative and use the same policy multiple times and just provide the unique tag for each instance. You can then either "DONOTENFORCE" or OVERRIDE the Effect to AUDIT, if this is your goal.

Are you asking for a single policy that can do the same?

[cjasset]

Thanks for the reply. I am aware of the built-in policies but as you point out, you would have to create an initiative and use the same policy over and over with 1 tag per policy. This isn't really scalable for both the customer and the ALZ team from a deployment perspective. Thats why I put together the attached policy which is a simpler solution. 1 policy, with an array of tags for input.

[mattfeltonma]

Suggesting a customer use the existing built-in policy which supports 1 tag per policy has the potential to create scale issues. There is no reason that we shouldn't be providing a built-in policy that supports multiple tags, which it looks like @cjasset has already provided.

What is the issue with getting the policy he has provided incorporated into the solution?

[Springstone]

No issue, just clarifying if the built-ins were considered. Just can't promise it in this refresh as we have a significant backlog (version pinning, etc), but will add it and hopefully we can get it in on time.

[Springstone]

PR is on the way, but will only be part of Policy Refresh in early Jan. Can't assign by default as customer needs to provide the tag array.

#1843