I have been playing around with the terraform module from Microsoft for the Azure Landing Zone (ALZ) for some time now. It is one of the technical implementation option for the ALZ under the CAF framework. While the module offers commendable features, its utilization and reverse engineering process can be intricate at time. I have collected the most useful elements I learned while using it. At the time of writing this I’m using the latest version (4.0.2).

New Archetype in 4 steps

This is well documented in the wiki from Microsoft, see the archetype definition wiki pages. However it lacks an high level overview of the steps that I found useful when working with the module.

• Write a new policy definition
  • This can be a policy definition or a policy definition set
  • Create it in the lib/policy_definitions folder
• Write a new policy assignment
  • Create it in the lib/policy_assignment folder
• Update/create an archetype
  • Create a new on in the lib folder
• Add the new archetype to the module parameter custom_landing_zone.

Input parameters for policy assignment

When creating policies it is useful to create some input parameters that can be assigned in the policy assignment. The module supports creating variables in the terraform configuration that can be used in the policy assignment. I find this feature a bit confusing in the documentation.

The parameter template_file_variables can take in variables that can be used in the policy assignment.

module "enterprise_scale" {
  source  = "Azure/caf-enterprise-scale/azurerm"
  version = "~>4.0"
  ....
  template_file_variables = {
    subscription_id_management = ""
  }
}

To use the input in the policy assignment see the example below:

{
    "name": "Sub-Input-Example",
    "type": "Microsoft.Authorization/policyAssignments",
    "apiVersion": "2019-09-01",
    "properties": {
      "description": "",
      "displayName": "",
      "notScopes": [],
      "parameters": {
            "sub": {
                "value": "${subscription_id_management}"
            }
      },
      "policyDefinitionId": "",
      "scope": "${current_scope_resource_id}",
      "enforcementMode": null
    },
    "location": "${default_location}",
    "identity": {
      "type": "SystemAssigned"
    }
}

Important: These values needs to be static values and not dynamic. This means that if you want to input a value from a terraform resources, like the ID for an resource group it will not work. This is because the module creates a map over the inputs and terraform don’t support dynamic keys.

Override resources

The advanced block that is part of the connectivity, identity and management settings can be used to override resources. Using the custom_settings_by_resource_type parameter allows for this. Under follows an example for overriding the identity parameter in the automation account.

module "enterprise_scale" {
  source  = "Azure/caf-enterprise-scale/azurerm"
  version = "~>4.0"
  ....
  configure_management_resources = {
    ...
    advanced = {
      custom_settings_by_resource_type = {
        "azurerm_automation_account" = {
          "management" = {
            "identity" = {
              "value" = {
                "type" = "SystemAssigned"
              }
            }
          }
        }
      }
    }
  }
}

But how do you know what types of resources and parameters that can be overridden? The simple answer right now is reverse engineering. Look for the lookup function and with some custom settings that is inputted. In most cases this parameter will have the option to be overridden.

identity = lookup(local.custom_settings_aa, "identity", local.empty_list)

Thoughts

Microsoft talks about the advanced blocks as following: Use of the advanced setting is currently undocumented and experimental. Please be aware that using this setting may result in future breaking changes.

Based on this is there is a likelihood that the code will break at some point. However Microsoft have gone to great lengths to allow for this sort of functionality so I belive that this type of functionality will only increase and improve the use of the module.

Summary

The ALZ module is a great way to accelerate the deployment of the infrastructure foundation. It have some great custom functionality and will fit most use cases. It lacks some documentation and getting started with can take some time. Functionality like overriding resources and inputting variables into assignments should definitely be better explained.

Overall a great contribution to the use of azure landing zone. Looking forward to further development.