Azure Policy: Compliance

The world of DevOps is continuously changing with constant idea of only one thing “Business Value”. An organisation has the expectation to continual delivery of new value, new capability for business and DevOps enables this.

And the most important is : In this new world of DevOps (Continuous Delivery/Continuous Deployment), we still need to ensure compliance and security are enforced.

Compliance Manager

In a compliance world, we have shared responsibilities related to configuration and compliance as customer and vendor. This is why Microsoft have these compliance solutions that show responsibility splits, enables us to track compliant state of the Microsoft services.

Compliance Manager: It has a number of templates built in related to a number of different requirements that we might want to adhere to, like for example : Infrastructure and virtualisation security.

Enforcing the Policy

So when deploy the components or make resource available via pipeline, We need to have all of these different types of base requirement defined. And what I want are these guardrails enforced by the actual fabric, not some specific deployment tool. We want Azure Resource Manager to be enforcing this via PowerShell or CLI or the portal or a JSON template or a Terraform and request should get enforced exactly the same way.

Azure Policy:

Using management groups helps us to manage access, policy, and compliance by grouping multiple subscriptions together. The Azure policies are really built on three main pillars:

• Enforcement and Compliance
• Policy at scale
• Remediation

We have a particular setting a policy. Now commonly, there’s more than one setting that’s going to meet our requirements. We don’t want to every time have to remember to assign different policies to this subscription or this resource group. Instead, we collect them into initiatives. So when we group them into an initiative, we not only can assign them based on the initiative, we can see the compliance based on the initiative. So we’ll see that rolled-up compliance state. We then have all the different scopes we can assign to any management group, multiple management groups, subscriptions, even resource groups.

Azure Policy Structure:

Let’s focus on 4 important details of structure of Azure Policy. Mode, Parameters, When to Apply (if), then. For example, the following JSON shows a policy that limits where resources are deployed:

Azure Policy is a realtime and violation-based engine. As we deploy things, it’s going to get checked as part of the Azure Resource Manager fabric. No matter what we do, if we are deploying via a devops-release pipeline, it’s still going to go through the policy, it’s still going to get checked for compliance.

Azure Policy As Code:

Policy can be managed and deployed as code. But why we want to use policy as code is in organisation?

In a more decentralised environment, the IT team might maintain policies as code, but then they just give us a subscription and then let run with it. The dev team would be responsible to pull the policy from the repository and then include it as part of the release pipeline, so it gets deployed at the start of each stage.

DevOps Pipeline Controls

The compliance gate is part of the Azure DevOps release pipeline. It is integrating with Azure Policy, but it’s focused around the compliance state.

Including this Check Azure Policy compliance. Now if by passing it a subscription, optionally a resource group, optionally a resource name, and adding a deployment gate, we also now have evaluation options because these checks may not pass the first time. So rather than just giving up, there’s a time it’s going to wait between reevaluation of the gates. If we have multiple gates, they all have to pass at the same time before it’s allowed to continue.