Skip to content

Leverage Azure Policy as Code to Automate Compliance Checks

Technology

Mar 9, 2021 - 5 minute read

Policy As Code In Azure 416X300
Adam Lepkowski Cloud Architect, Azure Practice Lead

Architect with over 10 years of IT delivery experience in diverse projects and environments. Currently, specialised in Azure cloud.

See all Adam's posts

2988 HC Digital Transformation 476X381

Share

Azure Policy is a crucial service that’s used to enforce and validate organisational standards. No matter if you work for a big corporation or a small company, there always are standards that need to be followed, when building a cloud solution. They may be internal company rules defined for resources created in the cloud by operations team, security team, or by the architecture board. There can also be external obligations, such as legal requirements — industries like healthcare or finance are heavily regulated.

In many companies, internal cloud standards are still described in a Word or PDF document. The defined rules are often divided into the following categories:

  • Security
    • Disks for virtual machines should always be encrypted.
    • App service should use an SSL connection.
    • Multi-factor authentication should be enabled.
    • SSH access should be blocked.

  • Cost
    • Allowed resource types — limits the resources your team can create to the particular types listed in the policy.
    • Allowed virtual machine SKU — defines what kind of machine can be used by your team. This way, you can disable access to expensive configurations.

  • Management
    • All resources have to be tagged.
    • Azure Monitor should track the virtual machine resources.

Imagine that your company has multiple teams and subscriptions, and a policy in form of a Word document describing standards that need to be followed in the cloud. If the policy compliance has to always be checked manually, there will be plenty of room for human error, and the environments won’t be consistent. Your operations team will spend a lot of time trying to verify whether your environment meets all the standards listed in the document. In many cases, they simply won’t do this work because they always have more important things to do. In this scenario, the communication overhead is way too high. Natural solution for such challenge, that is inline with the best DevOps practices, is to automate such activity and use Azure Policy.

Azure Policy provides over 500 built-in rules. It’s likely that most, or even all the standards that you want to follow are already defined in the service. You just need to select the ones that are relevant to your project. Of course, if you need something tailored specifically to your needs, you can always create your own custom rule.

Many rules available in the service are already grouped. For example, if your project has to comply with the ISO 270001 or the UK NHS, you can just select the right group, and Azure will enforce these legal requirements. Additionally, the communication effort between your teams is much lower, because the service allows you to manage rules, and automatically enforces that multiple teams comply with them. Monitoring options available in Azure allow you to see which subscriptions follow the rules. You won’t have to manually check whether all your existing environments comply with standards listed in a Word document.

How Does Azure Policy Work?

In Azure resources, there are two main objects:

  • Policy definition — the rule definition saved in the JSON format (i.e. tag is required).
  • Initiatives — groups of policies used mainly to simplify policy management.

The process of using Azure Policy looks like this:

  1. Create a policy definition or use the built-in definition.
  2. Create an initiative to group multiple policies if needed.
  3. Assign a policy definition or an initiative to a resource (management group, subscription, resource group, specific resource)
  4. View policy evaluation results (Azure Security Center, Azure Policy view)

Below you can see a sample JSON policy definition for a rule which doesn’t allow for creating a resource if a tag with appropriate value is not provided:

The definition consists of the three main sections:

  1. The properties section contains high-level information about the definition — name, category, version, et cetera.
  2. The parameters section allows for building generic rules. In this example, you can provide the required tag name and value. Parameter values are provided when:

    a. the policy definition is assigned to initiatives — you can specify the default value,
    b. the initiative or policy is assigned to a resource.

  3. The policy rule section contains a rule which will be used to evaluate resources, and the effect that‘s executed when the rule condition isn’t met. In this example, you can see that the “deny” effect is used. It means that a resource without a specified tag won’t be created.

Policy as Code

In most cases, using the Azure portal to manage the Azure Policy is sufficient, but when you have multiple teams and subscriptions, you can further improve this process. Instead of using the Azure Portal or various SDKs you can use a different solution that’s repeatable at an enterprise scale — you can adopt the policy as code approach.

In order to do it, you have to create a main repository where you’re going to store all policy definitions and initiatives. Policies and initiatives are going to be deployed into the environment where you’ll be able to verify whether they work correctly every time your operational team executes one of the following actions:

  • Create a new policy definition.
  • Update an existing policy definition.
  • Create a new assignment.
  • Update an existing assignment.

Policies and initiatives are deployed into an environment in which you may verify whether they work correctly. In this environment, you have the resources that you can use to test the Azure Policy configuration. When a configuration doesn’t comply with the policy, you can optionally execute the remediation task to introduce fixes. In the next step, you deploy them into your real project subscription or resource group. When the team makes all the changes in the dev environment, you can proceed with introducing the new configuration in other environments.

Summary

Azure Policy is a perfect service to implement governance for resource consistency, legal compliance, costs and security. Many built-in policies allow you to reduce the time required to introduce the entire process. Integration with Azure Security Center and the Azure Policy itself provide monitoring tools that enable you to determine where the rules are followed, and where there are problems.

It’s a great solution for large and small companies, because it allows you to reduce time spent on governance, and introduce the defined standards faster and more efficiently. It’s essential to choose the best approach for managing policies and initiatives. You can use a standard procedure which utilises the Azure Portal and different SDKs. You can also adopt the policy as code approach with the main repository and an entire pipeline dedicated to introducing changes. We recommend that you consider the specific needs of your company on your own, or with the help of an experienced partner, and determine the optimal way to introduce governance. You should remember that policy as code may be implemented by the project team itself or by the operation team. It all depends on your company structure and internal processes.

2988 HC Digital Transformation 476X381
Adam Lepkowski Cloud Architect, Azure Practice Lead

Architect with over 10 years of IT delivery experience in diverse projects and environments. Currently, specialised in Azure cloud.

See all Adam's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle