DEV Community: Greg Oliver

Test your Azure policies in parallel

Greg Oliver — Wed, 02 Dec 2020 15:46:50 +0000

This blog resulted from a customer development engagement. Want to read related blogs? Secure Azure as Code

Testing a policy is done with a few steps, each of which is a Terraform script:

Test the positive case, where the bad outcome the policy protects against is not challenged
Test the negative case, where the bad outcome is attempted (and hopefully audited or denied)
Both create and update use cases

If each test case requires creating a few Azure resources, the time to run these tests one after the other grows rapidly, especially in the case of testing policies. Having >100 policies to test is not unusual. Also, policies are normally defined at the management group level. This step can be done independently of the tests to set the context. Running the tests probably starts out by assigning policies to the test environment - a lower level management group or a subscription. Then the individual tests run on that test environment before it's reset with "terraform destroy".

Define policies and policy initiative in the management group

module "diagnostic_policies" {
  source                = "github.com/Nepomuceno/terraform-azurerm-monitoring-policies.git?ref=main"
  name                  = "DiagnosticsInitiative"
  management_group_name = var.definition_management_group
}

The Terraform script in the root folder of the github repo fully implements this step. It's done once before running any tests.

Run tests

In the tests folder of the github repo there are two approaches to this. One is implemented serially, the other in parallel. Both run the Terraform in the tests folder to do the policy assignment to the test environment. It also creates a couple of resources to use during tests that will follow.

Serial

func TestSerial(t *testing.T) {
    // setup the environment by assigning policy to the subscription
    options := &terraform.Options{
        TerraformDir: ".",
    }
    terraform.InitAndApply(t, options)
    defer terraform.Destroy(t, options)

    // run the first test
    t.Run("terraform_init_should_succeed", func(t *testing.T) {
        terraformTestOptions := &terraform.Options{
            TerraformDir: "./test-01",
    ... // and so on

Parallel

func TestParallel(t *testing.T) {
    // setup the environment by assigning policy to the subscription
    options := &terraform.Options{
        TerraformDir: ".",
    }
    terraform.InitAndApply(t, options)
    defer terraform.Destroy(t, options)

    t.Run("group", func(t *testing.T) {                 // <-- group the tests
        t.Run("terraform_init_should_succeed", func(t *testing.T) {
            t.Parallel()                                // <-- invoke Parallel()
            terraformTestOptions := &terraform.Options{
                TerraformDir: "./test-01",
    ... // and so on

Auto-start collection of Azure diagnostic telemetry

Greg Oliver — Wed, 02 Dec 2020 13:20:43 +0000

This blog resulted from a customer development engagement. Want to read related blogs? Secure Azure as Code

Infrastructure and platform monitoring are the province of Azure Monitor. The documentation provides several ways to configure diagnostic profiles on your resources so that the telemetry flows, but doing it onesy-twosy is a tax. Using Azure Policy together with an open source Terraform module allows this task to fade into the background - done and dusted.

Define policies and policy initiative in the management group

module "diagnostic_policies" {
  source                = "github.com/Nepomuceno/terraform-azurerm-monitoring-policies.git?ref=main"
  name                  = "DiagnosticsInitiative"
  management_group_name = var.definition_management_group
}

The Terraform script in the root folder of the github repo fully implements this step.

Assign policy initiative to your subscription

resource "azurerm_policy_assignment" "diagnostics_initiative" {
  name                 = "diagnostics-initiative-assignment"
  scope                = data.azurerm_subscription.current.id
  policy_definition_id = data.azurerm_policy_set_definition.DiagnosticsInitiative.id
  description          = "Policy Assignment created via terraform"
  display_name         = "Unit test diagnostic Logs application"
  identity {
    type = "SystemAssigned"
  }
  location = "uksouth"

  metadata   = <<METADATA
    {
    "category": "Logs"
    }
METADATA
  parameters = <<PARAMETERS
{
  "workspaceId": {
    "value": "${azurerm_log_analytics_workspace.ws.id}"
  },
  "storageAccountName": {
    "value": "${azurerm_storage_account.storage.name}"
  }
}
PARAMETERS
}

Give the SystemAssigned identity defined above rights to remediate

resource "azurerm_role_assignment" "contributor" {
  scope                = data.azurerm_subscription.current.id
  role_definition_name = "contributor"
  principal_id         = azurerm_policy_assignment.diagnostics_initiative.identity[0].principal_id
}

Scenario 01 in the scenarios folder fully implements these steps. Test by using a subscription that already has resources in it that do not have diagnostic profile(s) defined, or create new resources after running the above. Scenarios 02 and 03 are provided for convenience. They are dependent on scenario 01, so run scenario 01 first, then 02 or 03, etc.

Explanation and Background

Azure Monitor diagnostic profiles tell the platform what information you want to collect and where to send it. "What information you want to collect" is different for each resource type and there is no "everything" button. And that's the rub - one must make decisions for each resource in the system architecture. Using the module makes it possible to encapsulate all of this into one easy step in the Terraform script.

A project frequently equates to an Azure subscription, and there are usually multiple projects within an organization. Managing the resources in these projects is made more convenient through the use of Management Group and Azure Policy. From this page:

Azure management groups provide a level of scope above subscriptions. You organize subscriptions into containers called "management groups" and apply your governance conditions to the management groups. All subscriptions within a management group automatically inherit the conditions applied to the management group. Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have. All subscriptions within a single management group must trust the same Azure Active Directory tenant.

Using the module, many Azure policies and a policy initiative are defined (usually) at the management group level. Because each project team monitors their own infrastructure and each diagnostic profile designates the destination of the telemetry, it's best to assign the policy initiative at the subscription level. This allows the telemetry collection point to be within that subscription. It is possible to create multiple diagnostic profiles per resource so that telemetry can be directed to a global management point if desired.

Each policy defined by the module targets a resource type, such as network security group, virtual machine, network interface card, and so on. If a resource does not meet the requirements of the policy, a remediation task creates the diagnostic profile for the resource. When the module is assigned to the subscription (via terraform apply) the results are not instantaneous - the Azure policy engine may take up to 15 minutes to scan resources and run remediation tasks.

Standardize resource names in Terraform scripts

Greg Oliver — Tue, 01 Dec 2020 15:08:29 +0000

This blog resulted from a customer development engagement. Want to read related blogs? Secure Azure as Code

When starting a Terraform project for an Azure architecture, it's easy to come up with useful names for the resources in your architecture. They usually look like "my-resource-group', "my-public-ip", "my-vm", "mystorageaccount", and so on. When the architecture grows, or elements of it scale out, it becomes harder to design useful names that meet all requirements. This blog is about a tool that helps with this task.

If you agree with the above and just want a link to the tool, here it is: terraform-provider-azurecaf.

Usage samples are fully implemented in the scenarios folder of the github repo.

Everyone else, read on.

Requirements that must be met

for each resource type, rules vary
- length
- accepted characters
- accepted patterns (e.g. first character must be a lowercase alpha)
It must be possible to override generated names in special cases
It must be possible to generate globally unique names
Generated names must behave like any other resource in tfstate
- names persist across 'terraform apply' runs as long as name resource definition remains the same
- name resources can be destroyed, tainted, etc just like any other terraform resource

Additional nice-to-have features

a generated name should conform to a regular pattern that becomes familiar and instantly recognizable
when there are many resources in list, it should be possible to instantly recognize resource types from the name
clear and concise name generation code
when an architecture grows or resources scale out horizontally, name generation follows naturally
when testing permutations of resource properties, generating names is a very powerful enabling technique

Solution to the problem

The solution is a Terraform provider that generates resource names. Unsurprisingly, it meets all of the conditions above. Generated resource name configuration options include (in order of precedence):

name - overrides other options
slug - a few characters denoting the resource type
random - randomly generated chars
suffixes - an array of suffixes that are appended
prefixes - an array of prefixes that are pre-pended

All configuration options are defined in the provider repo.

The following examples are fully implemented in the scenarios folder of the github repo.

Generates and implements a resource group name similar to rg-xxxxxxxx (very simple example)

resource "azurecaf_name" "rg_name" {
  resource_type = "azurerm_resource_group"

  random_length = 8
}

resource "azurerm_resource_group" "rg" {
  name     = azurecaf_name.rg_name.result
  location = "uksouth"
}

Generates and implements a log analytics workspace name (example of name override)

resource "azurecaf_name" "ws_name" {
  resource_type = "azurerm_log_analytics_workspace"

  random_length = 8
  suffixes      = ["local"]
  name          = substr(data.azurerm_subscription.current.display_name, 0, 44)

  # desired outcome = log-<sub name>-xxxxxxxx-local
  # length = 3 + 1 + (44) + 1 + 8 + 1 + 5 = max of 63 characters for log analytics workspace name
  # 44 is the max # of chars to get from the subscription name in order to get everything else into the generated name
  # because the "name" parameter is an override, if more characters are used, other portions of the generated name will be truncated
}

resource "azurerm_log_analytics_workspace" "ws" {
  name                = azurecaf_name.ws_name.result

  ...
}

The resource name rules (such as the max length of 63 characters) for azurerm_log_analytics_workspace are in this file.

Generates multiple singleton names with a single azurecaf_name resource

resource "azurecaf_name" "names" {
  resource_type  = "azurerm_resource_group"
  resource_types = ["azurerm_lb", "azurerm_public_ip"]
  random_length  = 4
}

resource "azurerm_resource_group" "rg" {
  name     = azurecaf_name.names.result
  location = "uksouth"
}

resource "azurerm_public_ip" "pip" {
  name                = azurecaf_name.names.results["azurerm_public_ip"]

  ...
}

resource "azurerm_lb" "lb" {
  name                = azurecaf_name.names.results["azurerm_lb"]

  ...
}

Generates a set of names per vm instance of a cluster of vms

resource "azurecaf_name" "per_instance" {
  count = var.number_of_servers

  resource_type  = "azurerm_windows_virtual_machine"
  resource_types = ["azurerm_network_interface"]

  name          = "websvr"
  random_length = 4

}

resource "azurerm_network_interface" "nic" {
  count = var.number_of_servers

  name                = azurecaf_name.per_instance[count.index].results["azurerm_network_interface"]

  ...
}

resource "azurerm_network_interface_backend_address_pool_association" "example" {
  count = var.number_of_servers

  network_interface_id    = azurerm_network_interface.nic[count.index].id

  ...
}

resource "azurerm_windows_virtual_machine" "vm" {
  count = var.number_of_servers

  name                = azurecaf_name.per_instance[count.index].result
  network_interface_ids = [
    azurerm_network_interface.nic[count.index].id,
  ]

  ...
}