Policy as Code with Bicep and Terraform

Policy as Code (PaC) is the practice of defining and enforcing security and compliance policies through machine-readable code, integrated into the infrastructure deployment pipeline. In Azure, this primarily involves Azure Policy, which can be used to audit or enforce rules on resources. Bicep and Terraform are declarative IaC languages that define Azure resources. When combined with Azure Policy, they enable 'shift-left' security: catching violations at design time (during template validation) rather than after deployment.

The need for PaC arises because manual compliance checks are slow, error-prone, and inconsistent. In enterprise environments with thousands of resources, manual review is impossible. By codifying policies, organizations can automatically prevent misconfigurations like open network security groups, unencrypted storage accounts, or public blob access. Azure Policy evaluates resources against policy definitions and can deny creation, audit existing resources, or append tags.

Bicep is a domain-specific language (DSL) for Azure Resource Manager (ARM) templates. It compiles to standard ARM JSON. Terraform is an open-source IaC tool by HashiCorp that uses its own state management and provider model. Both can be integrated with Azure Policy through: - Built-in policy definitions: Azure provides over 1,000 built-in policies covering security, networking, storage, compute, and more. - Custom policy definitions: Written in JSON using the Azure Policy definition schema. - Policy initiatives (set definitions): Groups of policies that enforce a common goal, such as 'ISO 27001' or 'CIS Benchmark'. - Policy assignments: Apply policies to a management group, subscription, or resource group.

Integration Mechanism: 1. Design-time validation: When using Bicep or Terraform, you can run az deployment group validate or terraform plan to check resources against Azure Policy before deployment. This requires the 'Guest Configuration' extension or using the Azure Policy as Code workflow. 2. Deployment-time enforcement: Azure Policy denies non-compliant resource creation at the moment of deployment. The IaC tool receives an HTTP 403 (Forbidden) error, and the deployment fails. 3. Post-deployment audit: Policies set to 'Audit' will mark resources as non-compliant but not block them. This is useful for brownfield environments.

Azure CLI examples:

az policy definition list --query "[?policyType=='BuiltIn']" --output table

az policy definition create --name "deny-public-ip" --rules @policy.json --mode All

az policy assignment create --name "deny-public-ip-assign" --policy "deny-public-ip" --scope /subscriptions/{subscriptionId}

az deployment group validate --resource-group myRG --template-file main.bicep

terraform plan -var-file="prod.tfvars"

Bicep supports the resource keyword to define policy definitions and assignments directly in templates. Example:

resource policyDef 'Microsoft.Authorization/policyDefinitions@2021-06-01' = {
  name: 'deny-location'
  properties: {
    policyType: 'Custom'
    mode: 'All'
    displayName: 'Deny specific locations'
    policyRule: {
      if: {
        field: 'location'
        in: ['eastus', 'westus']
      }
      then: {
        effect: 'Deny'
      }
    }
  }
}

Note: mode must be set correctly. All evaluates all resource properties, Indexed only for resource types that support tags and location.

Terraform uses the azurerm_policy_definition resource. Example:

resource "azurerm_policy_definition" "deny_location" {
  name         = "deny-location"
  policy_type  = "Custom"
  mode         = "All"
  display_name = "Deny specific locations"
  policy_rule  = <<POLICY_RULE
{
  "if": {
    "field": "location",
    "in": ["eastus", "westus"]
  },
  "then": {
    "effect": "Deny"
  }
}
POLICY_RULE
}

Terraform also has azurerm_policy_assignment and azurerm_policy_set_definition resources. The azurerm_policy_virtual_machine_configuration_assignment is used for Guest Configuration.

Azure Policy evaluates resources and reports one of the following states: - Compliant: Resource meets policy conditions. - Non-compliant: Resource violates policy. - Conflict: Two or more policies conflict (rare). - Error: Evaluation failed (e.g., invalid policy rule). - Not started: Evaluation pending.

A common exam question asks: 'Which effect should you use to block non-compliant resource creation?' The answer is Deny. But candidates often choose Audit because they think it's safer. Audit only logs violations; it does not block. Another trap: Append can modify resources (e.g., add tags) but does not block creation. For blocking, use Deny.

A financial services company must ensure all storage accounts have encryption enabled. They create a custom policy definition that checks the encryption.services.blob.enabled property. If it is false, the effect is Deny. They assign the policy at the subscription level. The DevOps team integrates this into their Terraform pipeline. When a developer tries to deploy a storage account without encryption, terraform plan succeeds but terraform apply fails with a 403 error from Azure Resource Manager. The error message includes the policy name and reason. The team then uses the Azure Policy compliance dashboard to audit existing storage accounts; those without encryption are listed as non-compliant. They run a remediation task that enables encryption via a DeployIfNotExists policy. This scenario is typical in regulated industries where encryption is mandatory.

A large e-commerce company wants to control costs and ensure performance by allowing only specific VM SKUs (e.g., D2s_v3, D4s_v3). They create a custom policy using the Microsoft.Compute/virtualMachines/sku.name field. The condition uses notIn with a list of approved SKUs, and the effect is Deny. They assign the policy to the production subscription. The infrastructure team uses Bicep to define VMs. During deployment, the Bicep validation catches non-approved SKUs and fails the pipeline. Developers receive immediate feedback. The company also uses policy exemptions for a temporary test environment, with an expiration date. This prevents cost overruns and ensures consistency.

A common mistake is setting the policy mode to Indexed when the condition uses a non-indexed property (like encryption). This causes the policy to not evaluate the property, resulting in false compliance. Always use All mode for security-related policies. Another misconfiguration is forgetting to assign the policy to the correct scope; if assigned to a resource group instead of the subscription, resources in other resource groups are not evaluated. Also, using Append instead of Deny for blocking policies leads to resources being created but then modified, which may not be acceptable for security requirements.