Terraform | Reduction of manual effort when making changes to Tagging policies

[Winne004]

Hey @jesseloudon,

Thanks for sharing the code. We've used it as the basis for our Policy as Code approach. For context, we're using Terraform.

As it is early days in our Azure adoption, we're still trying to establish a tagging strategy that works for us. Therefore, I wanted a way to reduce work when making changes to the number and types of Key : Values that we enforced with policy.

The current approach requires that the list(map(string)) of tagging policies needs to be manually sized when calling the policyset_definitions module.

# terraform > main.tf 

 custom_policies_tag_governance = [
    {
      policyID = module.policy_definitions.addTagToRG_policy_ids[0]
    },
    {
      policyID = module.policy_definitions.addTagToRG_policy_ids[1]
    },
# ... and so on

In my implementation, I've boxed around this problem by using a for loop for the policy definition output:

# terraform > modules > policy-definitions > outputs.tf

output "RequireTagNameAndValueFromSet_policy_ID" {
  value       = [for k, v in azurerm_policy_definition.RequireTagNameAndValueFromSet : v.id]
  description = "List of strings of the policy definition IDs for RequireTagNameAndValueFromSet_policy_ID"
}

In main, I then pass:

# terraform > main.tf 

module "policy_initiatives" {
  source = "./modules/policy-initiatives"

  TagNameAndValueFromSet = module.policy_definitions.RequireTagNameAndValueFromSet_policy_ID # Already a list of strings
  addTagToRG             = module.policy_definitions.addTagToRG_policy_ids                   
  inheritTagFromRG       = module.policy_definitions.inheritTagFromRG_policy_ids             
  RequireTagOnResource   = module.policy_definitions.RequireTagOnResourcePolicyIDs

This provides me with a list of strings:

# terraform > modules > policy-policyset_definitions > variables.tf

variable "addTagToRG" {
  type        = list(string)
  description = "List of custom policy definitions for the monitoring network policyset"
  default     = []
}

Which I can then use to define a policy, as follows:

# terraform > modules > policy-policyset_definitions > main.tf

resource "azurerm_policy_set_definition" "Tagging_policies" {

  name                  = "Tagging_policies_sets"
  policy_type           = "Custom"
  display_name          = "Test: Tagging Policies"
  description           = "Contains Tagging Governance policies"
  management_group_name = var.MG_Name

  metadata = <<METADATA
    {
    "category": "${var.policyset_definition_category}"
    }
METADATA

  dynamic "policy_definition_reference" {
    for_each = var.TagNameAndValueFromSet
    content {
      policy_definition_id = policy_definition_reference.value
      reference_id         = policy_definition_reference.value
    }
  }

  dynamic "policy_definition_reference" {
    for_each = var.addTagToRG
    content {
      policy_definition_id = policy_definition_reference.value
      reference_id         = policy_definition_reference.value
    }
  }

  dynamic "policy_definition_reference" {
    for_each = var.inheritTagFromRG
    content {
      policy_definition_id = policy_definition_reference.value
      reference_id         = policy_definition_reference.value
    }
  }

  dynamic "policy_definition_reference" {
    for_each = var.RequireTagOnResource
    content {
      policy_definition_id = policy_definition_reference.value
      reference_id         = policy_definition_reference.value
    }
  }
}

I'm still learning Terraform, so my question is: Are there any disadvantages to this approach? I believe my approach reduces management overhead but am worried that I am setting myself up for a fail in the future.

I'd welcome any comments or feedback you may have,

J

[jesseloudon]

hey @Winne004

Great question! and apologies for the delay in coming back to you on this -- it's been some time since I've looked at my Terraform modules in this repo and needed to refresh my memory 😄

Your approach shown above certainly works well!

One disadvantage I can foresee:

• Adding new custom tag policy definitions (which aren't the same JSON as the existing) will require a new variable to be added to the initiative module and an additional dynamic block in resource "azurerm_policy_set_definition" "Tagging_policies". Not a management overhead if you are sticking to those existing custom policies and just incrementing the count based on variables.

Advantages I think also apply:

• Splitting up the custom tag policy definitions into their own respective initiative module variables and dynamic blocks allows for modular customisation in future (e.g. if you wanted to define parameters in your initiative only for certain tag policies).
• main.tf in the calling module looks compact/nicer 😄 because as you mentioned above, with your method, the custom_policies_tag_governance variable does not need to be manually sized when calling the initiative module if new custom policies are added.

Hoping this was helpful to you
Jesse

[Winne004]

Hi @jesseloudon,

Thanks for taking the time to respond; I found your answer really helpful!