Azure Enterprise Policy as Code (EPAC)

didierestevespro
May 5
5 min read

Original Medium link : Azure Enterprise Policy as Code (EPAC) | by Didier Esteves | Medium

The key points to know about Azure governance at a large-scale level.

I´ve just started new responsibilities for a new client when they told me that Enterprise Azure Policy as Code (EPAC) was already in place, and I must learn it.

Great! I already worked on Azure policies definition, the associated initiatives and how to deploy it automatically through PowerShell to a specified management group using Jenkins! It wouldn´t be so hard to learn!

Apart the official documentation that I read, let´s see on medium or YouTube to see what folks have shared… and I was quite disappointed to see that only one real post on this site and a few videos on the video platform… Why? I do not know to be honest.

Ok… So let´s dig into it.

EPAC is another level and brings a lot of advantages when it comes to managing a platform containing many (I said many) subscriptions & managements groups or event tenants.

First things comes first: what are we talking about ?

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

More precisely, EPAC is a mindset and a series of open-source PowerShell scripts that can be used with CICD pipelines for deploying, testing, maintaining policies and roles assignment on your organization.

As a reminder, a policy is an action that you configured to allow, deny, or audit some configurations to your services to have a real control of what exists in your cloud infrastructure. We distinguish two kinds of policies: the built-in ones (or out of the box provided by Microsoft or the cloud provider) and the custom ones (designed for your specific need). For example, you can create a custom policy that can prevent deploy a resource on a location that are not valid for your client.

In other words, you can bring governance and security to every subscription, resource groups and resources on a secured way, with automated scripts and can deploy policies updates as soon as they are available.

I strongly recommend EPAC for medium and large organizations otherwise you will have serious problems regarding time, cost and effort to deploy policies with other way (manually, or writing your deployment scripts for example).

Now we will talk about some advantages that I think relevant that every cloud solution architect should be aware of. I don´t want to explain in detail what is EPAC (the documentation above already do this well), but I want to point out some key elements for you to saving time.

Integration with Azure Landing zones

As part of Cloud Adoption Framework (CAF), Microsoft has a central repository of all policies that acts as a true source repo that every organization should have. So the idea is not to reinvent the wheel, but it´s to combine EPAC and Azure Landing zones good practices in order to implement good practices from Microsoft.

You already have deployed a lot of application and have an Azure organization in place? No problem ! the use of EPAC can be done even if you don’t start from scratch, this option can perfectly works.

This PowerShell command will automatically import all ALZ built-in policies to your local environment:

Sync-ALZPolicies -DefinitionsRootFolder .\Definitions -CloudEnvironment AzureCloud

Example of the folder structure with the policy definition files and the JSONs automatically imported :

CICD approach with integrated GitHub flow and Release Flow

From a DevOps perspective, teams can choose between GitHub flow and Release Flow for their branch strategy (or reuse the strategy already in place). In other words, the way they commit, manage the pull request and the size of the teams will depend of the choose between those strategy.

CICD approach is relevant about how to manage the version of your files, how to deploy using PRs and how to add a workflow before deploying anything to Azure.

We recommend GitHub flow for simplicity because we have fewer branch and it´s an easier approach and Release flow (often called Git flow) when we need more complexity — i.e. than the main and feature branch- and for larger projects.

In addition, EPAC provides a real integration using Azure DevOps pipelines and GitHub workflow: like this the integration using your existing knowledge and ALM techniques are still relevant.

Real tests before deploying to production

As I said, EPAC is not only PowerShell scripts and definitions files, but it´s also a mindset. Which means that teams can deploy and test their policies and role assignment to real managements groups/subscriptions before deploying it to the real production.

Wait… Do I understand it well?

Yes, EPAC brings you a model where you must configure at least two EPAC environments that encapsulate management groups. Thus, you can deploy and test your policies to “Dev EPAC environments”, perform every test that you want before submitting a Pull request for a merge in the main branch that will deploy to the real subscription production.

Example using the GitHub flow for deployment, we have PRs, two branches and two clear “EPAC environments” called PROD and EPAC-DEV :

You can import existing policies to your repository

Imagine that you have existing custom policies in your organization. You can use PowerShell command to import your policies to EPAC and save all the configuration files.

Important: the source of truth must be your EPAC repo because EPAC is declarative and idempotent: if a policy is not defined in your EPAC repo, it can be deleted in Azure.

Are we talking about Policy as Code isn´t right? Don´t be surprised!

Indeed, EPAC brings the concept of Desired state where you can adjust the default behavior of your EPAC environments regarding the policies and roles assignment. This state is defined through a .jsonc file extension, with some parameters that you can use to set what policies/roles do you want to implement, what do you want to exclude, the scope and out-of scope for your assignments.

This project is regularly maintained by the open-source community of Microsoft

Moving or adopting EPAC to an organization isn´t a choice to be made quicky because it will be the rock upon your Azure infrastructure will be built. That´s why it´s always a good idea to see how many releases exists over time, his frequency and how many contributors.

As you can see on this page, EPAC releases are between one and three weeks and 44 contributors are declared on this repo. Today, we have version 10 so we can be confident about his adoption to production.

Multitenancy is not a problem

In large-scale organizations, we often have more than one tenant each containing many Azure subscriptions. With EPAC, we can deploy our policies and roles assignments to more than one tenant from a single codebase on a central way. This brings consistency and simplifies the operations.

As you can see below of a extract of the global-settings.jsonc file, the tenantId properties allows us to target a specific tenant on a specific scope.

{    "$schema": "https://raw.githubusercontent.com/Azure/enterprise-azure-policy-as-code/main/Schemas/global-settings-schema.json",    "pacOwnerId": "00000000-0000-0000-0000-000000000000",    "pacEnvironments": [        {            "pacSelector": "epac-dev",            "cloud": "AzureCloud",            "tenantId": "00000000-0000-0000-0000-000000000000",            "deploymentRootScope": "/providers/Microsoft.Management/managementGroups/mg-Epac-Dev",            "desiredState": {                "strategy": "full",                "keepDfcSecurityAssignments": false,                "doNotDisableDeprecatedPolicies": false            },            "skipResourceValidationForExemptions": false,            "managedIdentityLocation": "eastus2"        },        {            "pacSelector": "tenant",            "cloud": "AzureCloud",            "tenantId": "00000000-0000-0000-0000-000000000000",            "deploymentRootScope": "/providers/Microsoft.Management/managementGroups/mg-Enterprise",            "desiredState": {                "strategy": "full",                "keepDfcSecurityAssignments": false,                "doNotDisableDeprecatedPolicies": false            },            "skipResourceValidationForExemptions": false,            "managedIdentityLocation": "eastus2",            "globalNotScopes": [                "/providers/Microsoft.Management/managementGroups/mg-Epac-Dev"            ]        }    ]}