Enterprise Policy as Code for Security & Governance - Part 1

Stephen Tulp
December 19, 2024

8 minutes to read

Azure Platform Engineering Advent Calendar 2024

Introduction

One of the five (5) Azure Landing Zone design principles is Policy-Drive Governance using Azure Policy to provide guardrails and ensure that deployed applications are compliant with an organisation’s governance requirements. Azure Policy provides application owners with independence and a secure, unhindered path to the cloud.

Azure Policy Refresher

Before we get into the details of the Enterprise Policy as Code (EPAC) solution, lets cover the key components of Azure Policy and what the relationship is between each component.

Policy Definition: An Azure Policy definition is a set of rules that describe the conditions under which a resource would be compliant and specify the effect if the resource is non-compliant. These definitions are in JSON format.
Policy Set Definitions: An initiative definition is a collection of policy definitions tailored toward achieving a singular overarching goal. Initiative definitions simplify managing and assigning policy definitions. They simplify by grouping a set of policies as one single item.
Policy Assignments: Policy assignments apply policy definitions or initiatives to a specific scope, such as a subscription, resource group, or management group. This ensures that the resources within that scope get evaluated for compliance with the policy’s rules.
Role Assignments: Role assignments are not directly part of the policy framework but are crucial for managing access and permissions within Azure. Policy assignments use managed identities for Azure resource authorisation. Either a system-assigned managed identity that gets created by the policy service or a user-assigned identity for deployIfNotExists effects.
Policy Exemptions: Policy exemptions in Azure Policy allow you to exclude specific resources or resource hierarchies from evaluation against certain policy definitions or initiatives. This can be useful when you need to temporarily waive compliance requirements for specific resources.

What is Enterprise Policy as Code?

Enterprise Policy-as-Code (EPAC) is an open-source community project that provides a CI/CD automation solution for the development, deployment, management and reporting of Azure policy at scale. EPAC maintains a Desired State to provide a high level of assurance in highly controlled and sensitive environments, and a means of managing policy exemptions.

Benefits of EPAC?

EPAC is a comprehensive and configurable solution that provides value and efficiency when managing Azure Policy at scale. Some of the benefits include:

Flexible Deployment: Using either single or multiple Microsoft Entra tenants.
Seamless CI/CD Integration: CI/CD workflows that are compatible with any CI/CD toolset.
Brown Fields Integration: Extract existing Azure Policy resources from an existing environment, even when no IaC is in place.
Address Azure Policy Complexity: Ensure deployments follow the required dependencies between different policy resources.
Simplify Operations: Dedicated scripts for operational actions that enable automation.
ALZ Integration: Integration with the Azure Landing Zone architecture.
Dedicated PowerShell Modules: Help deploy and manage the solution.

Who Should Use EPAC

EPAC has been designed for mature organisations with a larger implementation of Azure Policy and/or complex deployment scenarios (multiple tenants, multiple teams managing Policies). EPAC provides seamless integration with Azure Landing Zones and is highly recommended to complement this architecture.

Deployment Scripts

Three (3) deployment scripts provide the heavy lifting for the solution and plan a deployment, deploy policy resources, and assign roles based on the global settings defined in the global-settings.jsonc file (B).

The solution processes definition files (A) within structured folders. The planning script Build-DeploymentPlan.ps1 (C) generates plan files policy-plan.json and roles-plan.json (D), which are then used by the deployment scripts Deploy-PolicyPlan.ps1 (E) and Deploy-RolesPlan.ps1 (F).

These scripts require specific privileges Reader, Resource Policy Contributor, and User Access Administrator. Mandatory and optional approval gates governs each step and requires approval.

CI/CD Overview

EPAC uses PowerShell scripts for execution, which means any CI/CD toolset that has the ability to execute scripts is supported. The EPAC Repo contains starter pipelines and examples for Azure DevOps, GitHub and GitLab.

If we read the diagram from left to right

We are using Canary Microsoft Entra tenants, more details on this tomorrow but some extra information is here
The Platform Engineer creates a new Branch and commits IaC and code changes to the branch.
This triggers the Policy & Roles Plans against the canary tenant.
Then deployment of the Policies and the Role assignments against the canary tenant
We will also get the Policy & Roles Plans against the production tenant.
Once we are happy with the changes, a Pull Request will get created to merge these changes into the Main branch.
An Approver will approve the change and the Branch gets merged into Main.
This then triggers the Policy & Roles Plans again against the production tenant.
Optionally, an Approver will approve the changes and execute the Deploy Policy against the Production tenant.
Optionally, an Approver will approve the changes and execute the Deploy Roles against the Production tenant.

Tomorrow, we will go through this in details and run the deployment so that we can see how it all fits together.

Desired State Management

Desired State strategy can adjust the default behavior to cater for more complex environments, including shared responsibility scenarios. Within the global-settings.jsonc configuration file there is a desiredState element that controls the behaviour of the desired state management and includes required and options parameters.

"desiredState": {
    "strategy": "full",
    "keepDfcSecurityAssignments": false,
    "doNotDisableDeprecatedPolicies": false,
    "excludedScopes": [],
    "excludedPolicyDefinitions": [],
    "excludedPolicySetDefinitions": [],
    "excludedPolicyAssignments": []
}

The required parameters include:

strategy: The strategy to use for managing Policy resources:
- full: EPAC manages all Policy resources in the deploymentRootScope and its children. EPAC deletes any Policy resources not defined in the EPAC repo.
- ownedOnly: EPAC manages Policy resources defined in the EPAC repo. EPAC does not delete any Policy resources not defined in the EPAC repo.
keepDfcSecurityAssignments: Security and Compliance Initiatives should be at management group levels within EPAC.

The optional parameters include:

excludedScopes: An array of scopes to exclude from management by EPAC. The default is an empty array.
excludedPolicyDefinitions: An array of Policy Definitions to exclude from management by EPAC. The default is an empty array.
excludedPolicySetDefinitions: An array of Policy Set Definitions to exclude from management by EPAC. The default is an empty array.
excludedPolicyAssignments: An array of Policy Assignments to exclude from management by EPAC. The default is an empty array.
doNotDisableDeprecatedPolicies: Automatically set deprecated policies’ policy effect to Disabled. This setting can override that behavior by setting it to true. Default is false.
excludeSubscriptions: Exclude all subscription under the deployment root scope. Designed for environments containing frequently updated subscriptions that are not requiring management and where using excludedScopes would be impractical to maintain. Default is false.

Conclusion

EPAC is a powerful and feature rich solution for managing Azure Policy as Scale, bringing together IaC, Azure Policy and DevOps approaches makes this the defacto standard for Platform Engineering teams. Tomorrow we will go through an end-to-end deployment of the solution to understand the inner workings of the solution and showcase how you can use it within your environment.

Some further reading on EPAC: