Microsoft Azure Governance - Enforce Speed & Control Using Policy

This blog post describes how to achieve speed and control as part of cloud governance in Azure. This is Part 1 of a 5 part series. The next steps in the series will be shared in upcoming posts.

Introduction

Before starting any lecture related to cloud computing, I always try to remind students about the advantages of cloud computing.

Focusing strictly on Azure, I found it easier to classify the advantages of the platform within three categories:

Flexibility
Efficiency
Strategic Value

Cloud Advantages

Knowing these advantages and truly achieving them in a streamlined manner, are two different things.

According to Microsoft, companies around the world are responding to their customers' need for faster delivery with cloud computing. At the same time, compliance is increasingly important to ensure you have consistent standards across the environment, or to meet external needs.

Historically, companies have struggled with governance and, as a result, faced inevitable struggles:

Introducing the necessary control through traditional governance processes slowed down a company's ability to release new innovations, as they were often manual.
In some cases, companies didn't implement strong governance and, without these important controls in place, speedy development was not always compliant development.

Neither of these are ideal outcomes. It's clear that what customers need is both speed and control.

Cloud Governance

The need to govern is driven by organizations having:

Multiple engineering teams (deploying and operating in)
Multiple subscriptions
The need to standardize or enforce how cloud resources are configured
The requirement to satisfy regulatory compliance, create cost value, security demands, or achieve design consistency

By providing governance capabilities as part of the Azure platform, customers can implement policies and compliance earlier in the development process, thereby accelerating compliant development.

With Azure, you can create compliant environments from the very beginning instead of waiting for challenges or problems to arise. These services collectively represent the most complete, built-in governance offering in any public cloud - and the best part is they are all available to Azure customers at no additional cost.

For my studies and projects, I follow these 6 steps to build compliant environments geared towards speed and control:

Overall, Azure Governance services are designed to help customers:

Enforce internal standards and guardrails
Apply consistent security & management
Setup environments faster
Meet regulatory compliance requirements
Release compliant code faster
Control costs
Organize resources to match your organization

Create Policies Using Azure Policy

Azure Policy is a control service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, keeping them compliant with your corporate standards and service level agreements. Azure Policy meets this need by evaluating your resources for non-compliance with assigned policies.

For example, you can have a policy to allow only a certain VM SKU in your environment. Once this policy is implemented, new and existing resources are evaluated for compliance.

With the right type of policy, existing resources can be brought into compliance.

Azure Policy

The approach to creating a policy follows these steps:

Identify your business requirements
Map each requirement to an Azure resource property
Determine which effect to use
Compose the policy definition
Initiate the policy

Policy Definition

The journey of creating and implementing a policy in Azure Policy begins with creating a policy definition.

Before creating a definition, it's important to understand the intent of the policy. For example, a common enterprise security requirement be that each storage account must be enabled for HTTPS and disabled for HTTP.

A possible business requirement for the above policy could be defined as "preventing the creation of resources if they aren't compliant with business rules".

Your requirements should clearly identify both the "to be" and the "not to be" resource states.

Every policy definition has conditions under which it's enforced and a defined effect that takes place if the conditions are met. You can define policies by using either Built-in policies or Custom policies.

Policy Assignment

A policy assignment is a policy definition that has been assigned to take effect within a specific scope.

This scope could be:

A management group
A subscription
A resource group (a policy applied to a resource group is inherited by all the resources in that group.)

You can exclude a sub-scope from the policy assignment.

Policy Definition & Exclusion

Failed Deployment

Successful Policy Validation

Policy Parameters

Policy Parameters help simplify your policy management by reducing the number of policy definitions you must create.

You can define parameters when creating a policy definition to make it more generic. You can then reuse that policy definition for different scenarios. You do so by passing in different values when assigning the policy definition. For example, specifying one set of locations for a subscription.

Initiative Definition

An initiative definition is a collection of policy definitions that are tailored towards achieving a singular overarching goal. Initiative definitions simplify managing and assigning policy definitions, by grouping a set of policies as one single item.

For example, to meet the privacy laws of my banking client, all data must be stored within the African continent. Part of my strategy to meet this business requirement is to ensure that:

All compute resources must be created and stored in South Africa
All resource groups must be located in South Africa
Each compute resource must be in the same location as the resource groups

Azure Policy includes 3 built-in policies that meet my objective:

Audit resource location matches resource group location - Audits that the resource location matches its resource group location.
Allowed locations - This policy enables you to restrict the locations your organization can specify when deploying resources. Use this to enforce your geo-compliance requirements.
Allowed locations for resource groups - This policy enables you to restrict the locations your organization can create resource groups in. Use to enforce your geo-compliance requirements.

Considering these 3 policies help me achieve one objective, I will create a policy initiation that combines the functionality of the 3 individual policies, and then assign one initiative to my DevOps resource group.

Initiative Assignment

Like a policy assignment, an initiative assignment is an initiative definition assigned to a specific scope.

Initiative assignments reduce the need to make several initiative definitions for each scope. This scope could also range from a management group to a resource group.

Each initiative is assignable to different scopes.

DevOps resource group created in disallowed region should fail audit compliance checks

(Note that it takes roughly 30 minutes for an initiative or policy to be triggered. To learn more, read about Evaluation Triggers.)

Initiative Parameters

Like policy parameters, initiative parameters help simplify initiative management by reducing redundancy. Initiative parameters are parameters being used by the policy definitions within the initiative.

Azure Policy Effects

Each policy definition in Azure Policy has a single effect. That effect determines what happens when the policy rule is evaluated to match. The effects behave differently if they are for:

A new resource
An update resource
An existing resource

Consider these 6 conditions:

Append - used to add additional fields to the requested resource during creation or update. A common example is adding tags on resources such as costCenter or specifying allowed IPs for a storage resource.
Audit - used to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn't stop the request.
AuditIfNotExists - enables auditing on resources that match the if condition, but doesn't have the components specified in the details of the then condition.
Deny - used to prevent a resource request that doesn't match defined standards through a policy definition and fails request.
DeployIfNotExists - Similar to AuditIfNotExists, DeployIfNotExists executes a template deployment when the condition is met.
Disabled - makes it possible to disable a single assignment instead of disabling all of that policy's assignments.

Recommendation for Managing Policies

1.) Start with an audit effect, instead of a deny effect, to track the impact of your policy definition on the resources in your environment. If you have scripts already in place to autoscale your applications, setting a deny effect may hinder such automation tasks already in place.

2.) Consider organizational hierarchies when creating definitions and assignments. It is recommended that you:

Create definitions at higher levels, such as the management group or subscription level
Create the assignment at the next level. If you create a definition at a management group, the assignment can be scoped down to a subscription or resource group within that management group

3.) Create and assign initiative definitions even for a single policy definition. For example, you have policy definition policyDefA and create it under initiative definition initiativeDefC. If you create another policy definition later for policyDefB with goals similar to policyDefA, you can add it under initiativeDefC and track them together.

4.) Once you've created an initiative assignment, policy definitions added to the initiative also become part of that initiative's assignments.

5.) When an initiative assignment is evaluated, all policies within the initiative are also evaluated. If you need to evaluate a policy individually, it's better to not include it in an initiative.

Summary

Enterprises are increasingly adopting the public cloud for its agility and flexibility. They rely on the cloud's strengths to generate revenue and optimize resource usage for their business. Microsoft Azure provides a multitude of services and capabilities that companies assemble, like building blocks, to address a wide array of workloads and applications.

Deciding to use Microsoft Azure is only the first step to achieving the benefits of the cloud. The second step is understanding how an enterprise can effectively use Azure and identify base capabilities that need to be in place to address questions like:

"I'm concerned about data sovereignty. How can I ensure that my data and systems meet our regulatory requirements?"
"How do I know what each resource is supporting so I can account for it and bill it back accurately?"
"I want to make sure that everything we deploy or do in the public cloud starts with the mindset of security first. How do I help facilitate that?"

This post is a starting point for technical professionals to address the need for speed and control using Azure Policy.

In my next post, Step 2, I will cover how to achieve speed and control involving Management Groups.

Learn more about architecting resilient cloud applications with Microsoft Azure. Sign in with your All Access Pass, now!