Azure Policy Design and Assignment

Lesson: Azure Policy Design and Assignment

Introduction: What is Azure Policy?

In a cloud environment, managing compliance and governance at scale is a significant challenge. As your organization grows, maintaining consistency across hundreds or thousands of resources becomes impossible to do manually.

Azure Policy is a governance service that allows you to create, assign, and manage policies that enforce rules for your Azure resources. Think of it as the "guardrails" of your cloud environment. It evaluates your resources and highlights those that are not compliant with your assigned policies.

Why use Azure Policy?

• Enforcement: Prevent the creation of non-compliant resources (e.g., preventing the deployment of VMs in unauthorized regions).
• Compliance: Maintain industry standards (like ISO 27001 or PCI-DSS) by auditing existing resources.
• Cost Management: Enforce tagging policies to ensure every resource has a CostCenter tag, making it easier to track spend.
• Security: Ensure that public access is disabled on sensitive services like Storage Accounts or SQL Databases.

Designing Azure Policies

Designing effective policies requires a structured approach. Before writing code, you must define the "What" and the "How."

1. Definitions

A policy definition expresses what you want to evaluate and what effect to take.

• Policy Rule: The logic (If/Then) that defines the evaluation.
• Effect: What happens when a resource is evaluated (e.g., Audit, Deny, DeployIfNotExists, Modify).

2. Initiatives (Policy Sets)

An initiative is a collection of policy definitions grouped together toward a single goal. For example, a "Security Best Practices" initiative might include policies for enabling diagnostic logs, requiring encryption, and restricting public IP usage.

Practical Example: Restricting VM SKUs

Imagine you want to prevent developers from deploying expensive VM sizes (e.g., G-Series) to keep costs down.

Policy Definition (JSON)

{
  "properties": {
    "displayName": "Allowed VM SKUs",
    "policyType": "Custom",
    "mode": "Indexed",
    "parameters": {
      "allowedList": {
        "type": "Array",
        "metadata": { "description": "List of allowed VM sizes" }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
          { "field": "Microsoft.Compute/virtualMachines/sku.name", "notIn": "[parameters('allowedList')]" }
        ]
      },
      "then": { "effect": "deny" }
    }
  }
}

Assignment

Once defined, you must assign the policy to a scope. Scopes follow the Azure resource hierarchy:

• Management Group: The highest level; policies apply to all subscriptions within.
• Subscription: Policies apply to all resource groups within.
• Resource Group: Policies apply only to resources within that specific group.

Pro Tip: Always assign at the highest possible scope (Management Group) to ensure consistent governance across the entire organization.

Governance Strategies & Best Practices

Designing governance is not just about writing rules; it is about organizational maturity.

1. Use Built-in Policies First

Microsoft provides hundreds of built-in policy definitions (e.g., "Require a tag on resources"). Before creating custom policies, search the Azure Policy portal to see if a built-in one already meets your needs. It is easier to maintain and receives updates from Microsoft automatically.

2. The "Audit" Before "Deny" Pattern

Never jump straight to Deny for a new policy in a production environment.

1. Audit: Deploy the policy with the Audit effect first. This allows you to identify all non-compliant resources without breaking existing workflows.
2. Remediate: Work with teams to fix the non-compliant resources.
3. Deny: Once the environment is clean, update the policy to Deny to enforce the rule moving forward.

3. Use Parameters

Make your policies reusable by using parameters. Instead of hardcoding values like "East US" or "Standard_D2s_v3", define them as parameters so you can reuse the same policy definition with different values for different departments or environments.

Common Pitfalls to Avoid

• Over-complicating Logic: Complex logic in policy rules can lead to slower evaluation times. If a policy is too complex, consider splitting it into smaller, focused policies.
• Ignoring "Modify" and "DeployIfNotExists": Many admins only use Audit and Deny. However, Modify and DeployIfNotExists can automatically fix issues (e.g., automatically adding a missing tag or configuring a Storage Account to use HTTPS), reducing the operational burden on your team.
• Lack of Communication: Implementing Deny policies without notifying your development teams will lead to deployment failures and frustration. Always communicate governance changes before they take effect.
• Missing Exemptions: Sometimes, a specific resource needs to be non-compliant for a valid business reason. Use the Policy Exemption feature rather than deleting the policy or moving the resource to a different scope.

Key Takeaways

1. Governance as Code: Treat your Azure Policy definitions like application code. Store them in a Git repository, use CI/CD pipelines to deploy them, and version control your changes.
2. Hierarchy Matters: Use Management Groups to push consistent policies across your entire Azure footprint.
3. Start with Audit: Always assess the impact of a policy using the Audit effect before enforcing it with Deny.
4. Automation is Key: Utilize Modify and DeployIfNotExists effects to automatically remediate non-compliant resources, moving from "Governance by Detection" to "Governance by Correction."
5. Lifecycle Management: Regularly review your policy assignments. As your cloud architecture evolves, some policies may become obsolete or require updates.

Important: Azure Policy evaluation is not instantaneous. When you assign or modify a policy, it can take up to 30 minutes for the policy to take effect across existing resources. For new resources, evaluation happens during the deployment process.