Govern your Azure resources with simplicity

It is important to govern your Azure subscription. In this post you will learn how Azure Policy can help you govern your Azure subscription!

by | Dec 18, 2018 | Security

Introduction

DevOps represents a trend where a multi-disciplinary team gets responsible for the whole lifecycle of an application. Working with a DevOps team means that you can be more agile and release your application more often. A good example of a product that is built with a devops cadence is Azure DevOps (former Visual Studio Team Services).

Learn more about the DevOps trend at Gatner:
https://www.gartner.com/it-glossary/devops

Learn more about DevOps at Microsoft:
https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/

Having a good set of rules on how to work with software and infrastructure is really important. This ruleset should contain rules to make sure your environment is secured, and data is not leaving a certain region. As your teams can make changes to the environment at any moment, it is important to know if the environment is still compliant.

In this blogpost I’ll explain how you can convert your rules into policies and how you can report on the compliance state of your environment.

Design

I often work for customers who are starting with Azure or who have already been started but have no design or ruleset on which the environment should be compliant. In the case that there is no Azure design, I first start creating that design. Your Azure design should contain all decisions that your organization has made to “structure” the Azure environment. As you are working with DevOps teams, you should only include in your design what is necessary to have a secure and structured environment. Things that I normally include in such a design are:
  • Subscriptions & Regions – Here I describe al decisions that are made regarding subscriptions and regions e.g.: what regions will be used?
  • A resource group plan – This part of the design describes what a resource group should contain (not the exact resources, but rules e.g. all resources that follow the same lifecycle should be in the same resource group)
  • Azure Networking – Most of the time organizations leverage a VPN or ExpressRoute environment so they can securely access their Azure resources. In this part of the design I describe the network setup and its security.
  • Identity and Access – In this part of the design I have all the decisions described that are related to the Azure Active Directory and Role Based Access Control (RBAC).
More application related topics such as web apps, databases etc. should be designed by the DevOps teams. As multiple teams can interact with Azure, you want to make sure your Azure environment stays compliant with your design. One of the tools that you can use for this is Azure Policy. In Azure Policy you can define rules, report on the compliance state of those rules and enforce those rules. In this blogpost I will work with the following example design rule: Data should never leave Europe. Data should be stored as close as possible to the main office (located in the Netherlands) so latency is as low as possible. The West Europe region and North Europe region should only be used. The West Europe region is the closest region to the main office. As the West Europe region is paired with the North Europe region, it makes sense to use that region as disaster recovery region.

Setting up Azure Policy

In Azure Policy you can manage, assign and create policies. These policies contain rules that you can enforce on your resources, resource groups or the whole Azure subscription. After a policy is assigned, Azure Policy will evaluate your resources against the rules that are defined in the policy.

Azure Policy is a service that is available in every Azure subscription. You can access Azure Policy by navigating to the Azure Portal, hit the “All Services” button and click on “Policy.” This will open up the Azure Policy overview screen.

Create a policy for allowed location
To check if a subscription is compliant with the earlier described design decision, you should assign an Azure Policy to your Azure Subscription. Follow the instructions below to assign a policy to your Azure subscription which only allows you to deploy resources in West Europe and North Europe:

  • In the Azure portal click on All Services and navigate to Policy. The overview screen of Azure Policy is now displayed.
  • Click on Assignments. You will now see a screen which shows all the policies that are currently assigned within your subscription.
  • Click on Assign Policy to create a new policy assignment. You will now see a screen where you can define your policy assignment.
  • Use the following data:
    • Scope: Only select your subscription. We want this policy to be applied on the whole policy. If you also select a resource group, the policy is only applied to that resource group.
    • Exclusions: leave empty
    • Policy Definition: Allowed Locations
    • Description: “Policy assignment to make sure resources are only deployed in North and West Europe.”
    • Allowed Locations: North Europe, West Europe.
  • Click on Assign
  • The policy is now assigned to your subscription

The policy is now in place. If you navigate to compliance, you will probably see that the compliance state is “not started.” Azure checks the compliancy state of your resources with a certain interval. At this time, that check has not been executed yet.  After a couple of minutes you will see that the check has been executed and the state of your policy assignment has changed to “Compliant” or “Non-compliant.”

 

Policy in Action

As you saw in the previous part of this blogpost, policies can be used the report on the compliancy state of your resources. Azure Policy will also help you to stay compliant. It is not possible to deploy new resources that are not compliant. If you try to deploy a resource that is not compliant (in this example a resource that is not deployed in West Europe or North Europe) Azure Resource Manager will present an error when the resource deployment gets validated.

Working with Azure Policy at scale

In the previous sections you read about Azure Policy and how policies can be applied to subscriptions or resource groups. This works well is small environments. If you have to work on a large scale, you could apply policies on Management Groups

Management Groups
If your organization has many subscriptions, you need an effective way to do governance. Management Groups provide a level of scope above your Azure subscription. Multiple Azure subscriptions can be grouped into management groups. All subscriptions in a management group automatically inherit conditions (access, policies, etc.) applied to the management group. 

Policies can be applied to a management group. Subscriptions that are part of that management group will inherit the policies that are applied to the management group.  

Grouping subscriptions in Management Groups
Use the following “how to” to group multiple subscriptions in a management group:

  • In the Azure Portal, go to All Services and look for Management Groups
  • Click on Add management group and fill in the details for your management group:
    • Management Group ID – The identifier that is used by the Azure system (cannot be changed)
    • Management Group Display Name – The name that will be displayed in the portal
    • After filling in the above details, click on Save
  • After the management group is created click on the refresh button in the management groups blade, so the just created management group becomes visible.
  • Click on the just created management group and click on details.
  • Click on Add subscription, select the subscription that you would like to add to this management group, and hit the save button.
  • Repeat the above step for all the subscriptions that you would like to add to this management group.
  • Your management group is now ready! We can assign policies to it!

Assign a policy to your management group
Use the following instructions to assign a policy to a management group.

  • In the Azure Portal, go to All Services and look for Policy
  • Click on Assignments
  • Click on Assign Policy
  • For Scope, click on the “” button and select the management group that you just have created. Hit select to save your scope selection.
  • For Policy definition, click on the “” button and select the policy that you would like to assign (for example: Allowed Locations)
  • At the parameters section, fill in the parameters that come with the selected policy (in case of the “Allowed Locations” policy, you have to select the locations in which you want to allow resource deployments)
  • Click on Assign
  • The policy is now assigned to the management group. All subscriptions that are part of that management group, will now inherit the policy assignment from the management group. 

Learn more about management groups at: https://docs.microsoft.com/en-us/azure/governance/management-groups/ 

Custom Policies

Earlier in this blogpost a predefined policy (allowed locations) was deployed. Sometimes you could end up with a design decision that cannot be converted into a policy by using default policies. In that case you need to define a new policy definition. You can define your own policies by following the below instructions. In the below walkthrough we will define the same policy (allowed locations) but this time we define the policy by ourselves.
  • In the Azure portal click on All Services and navigate to Policy. The overview screen of Azure Policy is now displayed.
  • Click on Definitions. A screen that shows all policy definitions is now presented.
  • Click on “+ Policy Definition” you will now see a form where you can define your own policy.
  • Use the following data:
    • Definition location: Your Azure subscription
    • Name: “Allowed Azure Regions” (note that this name distinguishes from the predefined policy “Allowed Locations”)
    • Description: “Resources can only be deployed in certain configured regions”
    • Category: “Azure Regions”
    • Policy Definition:

{
  "policyRule": {
    "if": {
      "not": {
        "field": "location",
        "in": "[parameters('allowedLocations')]"
      }
    },
    "then": {
      "effect": "audit"
    }
  },
  "parameters": {
    "allowedLocations": {
      "type": "Array",
      "metadata": {
        "description": "The list of allowed locations for resources.",
        "displayName": "Allowed locations",
        "strongType": "location"
      }
    }
  }
}
  • Click on Save.
  • Navigate to the policy that is just created (Allowed Azure Regions)
  • Click on Assign
  • Use the following input:
    • Scope: Only select your subscription. We want this policy to be applied on the whole policy. If you also select a resource group, the policy is only applied to that resource group.
    • Exclusions: leave empty
    • Policy Definition: Allowed Locations
    • Description: “Policy assignment to make sure resources are only deployed in North and West Europe.”
    • Allowed Locations: North Europe, West Europe.
  • Click on Assign.
If you followed both the walkthrough for the custom policy and the predefined policy, you probably have two policies applied. In order to test the custom policy, you need to unassign the predefined policy “Allowed Locations.” You can unassign a policy by following the below instructions:
  • In the Azure portal click on All Services and navigate to Policy. The overview screen of Azure Policy is now displayed.
  • Click on Assignments. You will now see a screen which shows all the policies that are currently assigned within your subscription.
  • Look for the policy that you want to unassign and click on “” at the end of the policy entry.
  • Click on Delete Assignment. Your policy is now unassigned from your subscription.

Azure Policy Samples at Github

There is a github repository which contains samples of Azure Policies that can be used as reference for creating and assigning policies to your Azure subscriptions, resource groups and management groups.

Conclusion

With the DevOps trend it is really important to govern your Azure environment. When you do not govern your Azure subscription it will drift away quickly from the design that has been created.

As DevOps teams work agile, you should also work on an agile way with your Azure design. The design should be updated when Microsoft has new features available that impact your design; also, when business requirements change, you should also revisit your design.

Azure Policy is a service that can also be used on large scale. You can organise your subscriptions in management groups and assign policies to these management groups. By doing so, you keep your policy assignments maintainable. 

 

More information

Aside from this blogpost, I also recorded a vlog where I explain and demonstrate how Azure Policy is working.