What you Need to Know About Managing Azure Policy at Scale
The Azure Policy service for governance and compliance can be hard for enterprise organizations to navigate. Read on for expert guidance on rollout and management.
Microsoft’s Azure Policy service helps Azure customers govern and enforce compliance across security best practice, industry regulations and cost optimization initiatives.
From a security perspective, it might be used to ensure a particular version of Transport Level Security (TLS) is used. Regulatory measures or guidance from organizations such as the Center for Internet Security (CIS) can be enforced against specific resources. And in terms of cost management, it might limit the use of resources from Azure’s higher tier stock keeping units (SKUs).
In short, there's a wide range of use cases for Azure Policy, and many possible configurations. This diversity and complexity can result in analysis paralysis, stalling rollouts. It can also lead to the misconfiguration of settings, with a negative impact on productivity, security, and developer experience. Consequently, we sometimes find that enterprise organizations struggle to use this service effectively. It's especially challenging for those dealing with brownfield scenarios where non-compliant legacy resources are deployed in an Azure tenant.
What Does Microsoft Recommend?
Tools published by Microsoft to aid Azure Policy rollout include its Enterprise Azure Policy as Code (EPAC) overview and the Enterprise Scale Landing Zones (ESLZ) Terraform module. While both offer viable solutions, several factors may impact overall effectiveness.
For instance, EPAC is a PowerShell-based tool, following a unique workflow which has a steep learning curve. The ESLZ Terraform module presents different challenges. It manages many aspects of the Azure landing zone estate, not just Azure Policy configuration. So, if a platform team is already deploying other components through another mechanism, it may not make sense to use this module. What's more, the module frequently receives updates which the platform team need to keep up with. Sometimes the updates include breaking changes which can be complex to mitigate.
An Alternative Approach for Azure Policy Rollout
At Amdocs we recommend an alternative method for the rollout of Azure Policy. It involves use of Terraform or Bicep combined with a pipeline orchestrator such as Azure DevOps or GitHub Actions to deploy Azure Policy initiatives.
This aligns with the tooling typically used by platform teams when deploying other Azure resources. In addition, these tools are fantastic for previewing changes before deployment, as well as rolling back to previous configurations if needed. The approach should be combined with Microsoft's recommended use of Deployment Rings where updates are gradually rolled out to subsets of an IT organization.
A drawback of the EPAC and ESLZ rollout methods is that once an initiative is deployed and enforced, it's difficult to update it incrementally in a controlled manner. Amdocs' unique solution for this is to use dual-policy assignments, based on the ‘cumulative most restrictive' principle within Azure Policy. This principle ensures that the most restrictive policy definition takes effect when it is present in multiple active policy assignments. It means organizations can roll out incremental changes in audit mode (which merely tracks resource non-compliance) without impacting the wider initiative that may already be enforced (blocking resource non-compliance). This helps prevent scenarios where resources may have a window of opportunity to become non-compliant again during policy rollout.
Technical Considerations for Azure Policy Deployments Policy Design
There are three core Azure Policy definition types: Built-In, Custom and Remediation:
- Built-In Policy definitions are maintained by Microsoft and cannot be modified.
- If modification is required, a Custom Policy definition can be used but it must be maintained by the platform team.
- Remediation Policy definitions are used to alter non-compliant resources, making them compliant.
Combining multiple Azure Policy definition types in a single initiative is not recommended. Using one definition type avoids complicating the rollout process. It also aligns with the principle of least privilege, as remediation policies could require elevated permissions to change resource configurations.
Built-In definitions (such as the CIS Community Defence Model 2.0) should be used wherever possible. For one thing, conversations with auditors are more straightforward when they can see the default Microsoft definition is in place. Furthermore, there shouldn’t be any need for manual intervention to maintain alignment when Microsoft issues updates. Custom Policy definitions should only be used where a Built-In definition does not meet business requirements.
Policy as Code
When it comes to the implementation of Azure Policy at scale, separating initiatives across multiple source code repositories is key. Using a single repository for storage makes Terraform Plans or Bicep 'what-if' outputs very difficult to read. It also makes source code versioning difficult as the boundary consists of multiple Azure Policy initiatives that will likely have different lifecycles.
When a unique source code repository is used for each Azure Policy initiative, Git tags can be used to manage version numbering. Corresponding tags can then be used for resources deployed onto Azure.
It’s also advisable to host pipeline templates and Infrastructure-as-Code (IaC) modules for Azure Policy resources in a central repository. This ensures all initiatives follow a consistent approach at scale. The following diagram shows how this could be achieved with Terraform and Azure DevOps CI/CD pipelines:
Improving the Developer Experience
It's important to consider the developer experience in Azure Policy rollouts. Typically, if a developer attempts to deploy a non-compliant resource, they receive a generic statement that deployment is denied, with no guidance on how to achieve compliance. We advise customizing the non-compliance message. For instance, it could include a link to documentation detailing options on how to fix the error.
Where time pressures or technical constraints are a factor in non-compliance, developers may be granted an exemption, temporarily waiving policy enforcement. This provides a window to remediate the resource, as long as the developer has a valid business case to do so. Implementing a customized exemption creation pipeline – accessed by developers with approval from the security team – facilitates the management of policy exemptions at scale. Without this, exemption is a manual process in the Azure Portal that does not scale or provide a native approval flow.
When the Deployment Rings pattern is used for rollout, development and testing environments should receive changes before production within the Software Development Lifecycle (SDLC). This is crucial as it gives development teams early visibility of breaking changes in production, providing an opportunity to plan remediations via a refactor or a temporary exemption.
To assist with remediation, standardized and pre-approved IAC modules should be made available to development teams so they can be consumed on a self-service basis. These modules should also be Azure Policy compliant and validated for production use by security teams. Providing IAC modules in this way can help with general IAC adoption in scenarios where development activities are decentralized and teams work in isolation.
Look Out for Upcoming Azure Policy Features
At the time of writing, several new Azure Policy features are in public preview. These include the Resource Selectors functionality which will allow specific resource types (e.g. Storage Accounts) or Azure regions (e.g. UK South) to be targeted. This will further enhance the Deployment Ring rollout process. Another interesting feature, Built-in Initiative Versioning, will enable teams to control Built-In Policy definition updates with semantic versioning.
An Enterprise Lens on Azure Policy
The recommendations outlined here can facilitate a more scalable and predictable approach to Azure Policy rollout and maintenance. From an enterprise perspective, it's best to devise a customized approach that includes standardized IaC modules to help developers deploy compliant resources. Amdocs has a strong track record helping enterprise organizations with projects of this nature via consultancy and platform engineering services. We can also support in-house engineering teams, upskilling them to handle Azure Policy configuration confidently and effectively. Get in touch to discuss how we can support your use of Azure Policy at scale.
