Taking control of your Azure resources – Part 2 – Policies

The other day I wrote about the features Azure Resource Manager provides to let you take control of the resources you deploy. Today I will dive into the first of these features: Policies

Policies lets you manage how and which resources are created, by denying creation of resources that doesn’t follow the policies. For example you might want to follow a naming convention, or deny certain regions from being used. It’s worth mentioning that policies will effect all ways of interacting with the resources, wether it’s portal, PowerShell, API’s.

Policies are assigned at Resource Group level, meaning that all resources created within the Resource Group, will be affected by the policy. This also means that if users has Owner or Contributor role assigned, they can still create Resource Groups and workaround your policies that way. By default, if something is not explicitly denied, it will be allowed. While RBAC focuses on user access, policies work at the resource level, by preventing resources from being created if they don’t meet requirements. The two features go hand in hand though, and together helps you secure and control your environment.

Policies use the JSON format, just like ARM templates. Starting of, policies basically contains Conditions, Logical Operators and Effect

Conditions can contain these values:

Equals
Like
Contains
In
ContainsKey

The Logical Operators is:

Not – Checks a single condition, or logical operator
And – All conditions must match
Or

Effect can be either:

Deny – Denies creation of resources
Audit – Audits creation of resources by logging an event to the Audit Logs

To specify what the policy should check, we use Field and Source. At the moment Source only supports ‘action’ which refers to an action on the resource provider. Field supports the following values:

Name
Kind
Type
Locations
Tags

Okay, let’s take a closer look at the code:

{
"if": {
"not" : {
"field" : "tags",
"containsKey" : "Owner"
}
},
"then" : {
"effect" : "deny"
}
}

The above example will deny resources that does not have a tag of “Owner” defined. Owner in this case could be the person responsible for the resource.

Another scenario, which I really like, is the “Name” field. It let’s you enforce a naming convention to your resources, very cool! My example beneath denies resources that doesn’t start with “puzzles-“:

{
"if": {
"not": {
"field": "name",
"like": "puzzles-*"
}
},
"then" : {
"effect" : "deny"
}
}

Now, to assign the policy is a 2 step process. First you need to upload your policy definition:

[powershell]
$policy = New-AzureRmPolicyDefinition -Name serverNaming -Policy D:AzurePoliciesnamingPolicyazuredeploy.json
[/powershell]

This can also be done without saving the file, by using PowerShell only:

[powershell]
$policy = New-AzureRmPolicyDefinition -Name namingPolicy -Policy ‘{ "if" : {
"not" : {
"field" : "name",
"in" : "puzzles-"
}
},
"then" : {
"effect" : "deny"
}
}’
[/powershell]

Personally I like to save the file for future needs, and use that. It’s also more readable I think.

Next you need to assign your policy to a Resource Group:

[powershell]
$subscription = Get-AzureRmSubscription -SubscriptionName Cloudpuzzles
$resourceGroup = Get-AzureRmResourceGroup -Name demo-rg
$scope = "/subscriptions/" + $subscription.SubscriptionId + "/resourceGroups/" + $resourceGroup.ResourceGroupName
New-AzureRmPolicyAssignment -Name serverNaming -PolicyDefinition $policy -Scope $scope
[/powershell]

Now when I try to add a resource that doesn’t contain puzzles- in the name, it will fail:

That’s all there is to policies, but I guess there will soon be more policies to work with.
Also, make sure you check out the other PowerShell cmdlets to manage policies: