Understanding Azure Policy Effects: A Comprehensive Guide

Azure Policy is a powerful tool within Microsoft's Azure cloud platform that helps ensure your resources are compliant with your corporate standards and service-level agreements. By defining policies, you can enforce various rules and effects over your resources to maintain consistency, security, and governance. This blog will delve into the different types of Azure Policy effects, illustrating their purpose and how they can be effectively used to manage your Azure environment.

What is Azure Policy?

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, ensuring those resources stay compliant with your corporate standards and service-level agreements. Azure Policy evaluates resources in your environment and highlights resources that aren't compliant with the policies you’ve created. The service can also take action on non-compliant resources.

Types of Azure Policy Effects

Azure Policy effects are the actions that a policy rule will enforce when it is triggered. Understanding these effects is crucial for leveraging Azure Policy to its full potential. Below are the primary types of effects available:

1. Deny

The Deny effect is used to prevent a specific action from occurring. If a resource or action does not comply with the policy, the Deny effect will block the operation.

Use Case:

• Preventing the creation of resources in a specific region.
• Blocking deployment of VMs with unapproved images.

{
  "if": {
    "field": "location",
    "equals": "unapprovedRegion"
  },
  "then": {
    "effect": "deny"
  }
}

2. Audit

The Audit effect doesn't block the action but logs the non-compliant resource in the policy compliance state. This effect is useful for monitoring and reporting purposes without enforcing immediate restrictions.

Use Case:

• Tracking the use of non-standard SKUs for VMs.
• Logging untagged resources for later review.

{
  "if": {
    "field": "sku.name",
    "notIn": ["Standard_D2_v2", "Standard_F2"]
  },
  "then": {
    "effect": "audit"
  }
}

3. AuditIfNotExists

The AuditIfNotExists effect checks if a specified condition is met and, if not, audits the resource. This is commonly used to ensure related resources or configurations are present.

Use Case:

• Ensuring that network security groups (NSGs) are attached to subnets.
• Checking if diagnostic settings are enabled for key services.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "not": {
          "field": "Microsoft.Compute/virtualMachines/networkProfile.networkInterfaces[*].id",
          "exists": "true"
        }
      }
    ]
  },
  "then": {
    "effect": "auditIfNotExists",
    "details": {
      "type": "Microsoft.Network/networkSecurityGroups"
    }
  }
}

4. Append

The Append effect adds a specified configuration or setting to a resource during its creation or update. It does not block the action but ensures the required settings are included.

Use Case:

• Appending tags to all newly created resources.
• Adding required configurations to storage accounts.

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Resources/subscriptions/resourceGroups"
  },
  "then": {
    "effect": "append",
    "details": {
      "field": "tags.environment",
      "value": "production"
    }
  }
}

5. Modify

The Modify effect is similar to Append but more powerful. It can alter existing configurations on resources to ensure compliance.

Use Case:

• Modifying the SKU of a resource to an approved value.
• Enforcing specific configuration settings on virtual machines.

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Compute/virtualMachines"
  },
  "then": {
    "effect": "modify",
    "details": {
      "roleDefinitionIds": [
        "/providers/microsoft.authorization/roleDefinitions/{roleDefinitionId}"
      ],
      "operations": [
        {
          "operation": "addOrReplace",
          "field": "tags.mandatoryTag",
          "value": "true"
        }
      ]
    }
  }
}

6. DeployIfNotExists

The DeployIfNotExists effect automatically deploys a specified resource if it does not already exist. This is useful for ensuring that critical infrastructure components are always present.

Use Case:

• Ensuring that a specific monitoring agent is installed on all VMs.
• Deploying a required resource when another resource is created.

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Compute/virtualMachines"
  },
  "then": {
    "effect": "deployIfNotExists",
    "details": {
      "type": "Microsoft.Insights/diagnosticSettings",
      "existenceCondition": {
        "field": "Microsoft.Insights/diagnosticSettings/logs[*].enabled",
        "equals": "true"
      },
      "roleDefinitionIds": [
        "/providers/microsoft.authorization/roleDefinitions/{roleDefinitionId}"
      ],
      "deployment": {
        "properties": {
          "mode": "incremental",
          "template": { }
        }
      }
    }
  }
}

Conclusion

Azure Policy is an essential tool for maintaining governance and compliance in your Azure environment. By understanding and effectively using the various policy effects such as Deny, Audit, AuditIfNotExists, Append, Modify, and DeployIfNotExists, you can ensure your resources are managed according to your organization’s standards. These policies help not only in enforcing compliance but also in automating the remediation of non-compliant resources, thereby streamlining the management of your Azure infrastructure.

Implementing Azure Policy requires careful planning and a thorough understanding of your organization’s requirements. Start small, monitor the impacts, and gradually enforce stricter policies to achieve a robust and compliant cloud environment.