Before deploying anything in Azure you should think about Governance. You must address the topic of governance early to ensure the successful use of the cloud within your enterprise. After a series of really intense governance workshops my customer was ready to apply the decisions made from those workshops in Azure. In those workshops we define for example:
Well-designed naming standards enable you to identify resources in the Azure portal, on an invoice, and within PowerShell scripts. Most likely, you already have naming standards for your on-premise infrastructure. When adding Azure to your environment, you should extend, and be consistent with those naming standards to your Azure resources. Naming standard facilitate more efficient management of the environment at all levels. Review and adopt where possible the Patterns and Practices guidance.
As users in your organization add resources to the Azure subscription, it becomes increasingly important to associate resources with the appropriate department, owner, and environment. You can attach metadata to resources through tags. You use tags to provide information about the resource or the owner. Tags enable you to not only aggregate and group resources in various ways, but also to use that data for the purposes of chargeback. You can tag resources with up to 15 key:value pairs.
Resource tags are flexible and should be attached to most resources. Examples of common resource tags are:
- Department (or Business Unit)
- Environment (Production, Stage, Development)
- Tier (Web Tier, Application Tier)
- Application Owner
To address data sovereignty issues, my customer only wanted to allow Azure Resources to be deployed in 2 specific regions whereas Azure provides regions across the world. Enterprises often wish to control where resources are created (whether to ensure data sovereignty or just to ensure resources are created close to the end consumers of the resources).
One way of applying these governance decisions is with Azure Resource Policies.
Resource policies enable you to establish conventions for resources in your organization. By defining conventions, you can control costs and more easily manage your resources. For example, you can specify that only certain types of virtual machines are allowed, or you can require that all resources have a particular tag. Policies are inherited by all child resources. So, if a policy is applied to a resource group, it is applicable to all the resources in that resource group.
In this blog post and the upcoming two blogposts I will show you how you can create JSON Azure Resource Policy templates and re-use those policies in multiple different environments. There are two concepts to understand about policies:
- Policy definition – you describe when the policy is enforced and what action to take (we will define this in a JSON file)
- Policy assignment – you apply the policy definition to a scope (subscription or resource group). This will be a Deployment PowerShell Script.
As I need to create and assign more than one resource policy I’m going to script the Policy deployment and assignment. The script will have the policy JSON file as an input and deploy it to the Azure subscription.
- This blogpost will cover how to create a deployment Powershell Script to deploy and assign Resource policies. We will then deploy a tagging policy as an example
- In the second blogpost we will deploy a Location policy to limit the Azure locations and ensure data souvereignty
- In the last blogpost we will deploy a policy to enforce our naming convention
Let’s create our resource policies definition based on JSON. The policy definition contains elements for:
- display name
- logical evaluation
Have a look here for more information regarding policy constructs. You first start with a policy definition that’s created using JSON (you can see the schema here: http://schema.management.azure.com/schemas/2015-10-01-preview/policyDefinition.json) and which consists of one or more logical or condition operators that define the action and effect of the policy when a specific condition is achieved. So in our scenario we are checking if the field tags is false then append the field tag with a tag name and a default value. You can find the Resource policy I created below:
In this example we were applying Append, but there are more:
- Deny: Blocks the resource request
- Audit: Allows the request but adds a line to the activity log (which can be used to provide alerts or to trigger runbooks)
- Append: Adds specified information to the resource. For example, if there is not a “CostCenter” tag on a resource, add that tag with a default value.
Any new resources created within the specified subscription will have those tags that we defined in our JSON file appended to it.
Assigning Azure Resource Policies with PowerShell
Now that we have our tags defined we need to deploy and assign the policy to our Azure subscription. As I will deploy more than one policy I’m going to use PowerShell to make my life easier. Before proceeding with the PowerShell script, make sure you have installed the latest version of Azure PowerShell. Policy parameters were added in version 3.6.0. If you have an earlier version, the script returns an error indicating the parameter cannot be found.
The script requires the following parameters:
- Policy name
- Policy description
- Policy file (this is the full path to the JSON policy definition file)
You then need to specify the subscription to assign the Policy definition. Policies are inherited by all child resources. So, if a policy is applied to a subscription, it is applicable to all the resource groups and resources in that subscription.
View the code here
Run the above script with the required parameters:
That’s it! You have now created a new Azure Resource Policy definition and assigned that Policy to a subscription!
After running the script and assigning the tagging policy you should see the following policy assigned to our subscription:
and as you can see, when we create a new resource without tags, they willl be appended automatically:
In the next blog post we will use the same PowerShell script but create and assign a policy to limit the Azure regions. So stay tuned!
Hope this helps,