Overcast » April 24, 2016

Daily Archives: April 24, 2016

Policies Resource Manager

Azure Resource Manager Policies

Published by:

In a real world scenario, policies and restrictions will be something you are going to need on a daily basis. In times of infinity capacity clouds, it is very important that you can control what and how much can be deployed. In the previous Azure portal, that task was very hard. With the addition of RBAC (Role Based Access Control), this task added an important capability to the mix. However, that was not enough to give more granular control on what kind of resources could be deployed.

Enters ARM Policies. With Policies you can essentially determine the conventions for specific subscriptions, resource groups or resources, in terms of what is allowed to be done or not.

With Policies, you can , for example, determine what types of resources a user (authorized with RBAC) can deploy and to which regions.

Let’s take a look at how it is done. In my example, I will create a resource group, then restrict the types of resources you can deploy in it.

First, creating the RG:

Add-AzureRmAccount
$RG=New-AzureRmResourceGroup -Location “East US” -Name “PolicyRG”

Now, let’s define a policy. Each policy contains basically conditions and effects:

$PolicyDef1=@”
{
  “if”: {
    “not” : {
      “field” : “tags”,
      “containsKey” : “costCenter”
    }
  },
  “then” : {
    “effect” : “deny”
  }
}
“@

This particular policy only allows deployment of resources that have a costCenter tag.

The next step is to create the actual policy object:

$policy = New-AzureRmPolicyDefinition -Name tagPolicyDefinition -Description “Policy to allow resource creation only with Tags” -Policy $PolicyDef1

And apply it to a certain scope. In this case, my resource group:

New-AzureRmPolicyAssignment -Name tagPolicyAssignment -PolicyDefinition $policy -Scope $RG.ResourceId

Now if you try to deploy any resource without the specific tag, you will be blocked:

image

If you use PowerShell and create, for example, an external IP with a tag, you will be ok (

$publicIP = New-AzureRmPublicIpAddress -Name $PublicIpName -ResourceGroupName $rgName -Location $locName –AllocationMethod Static -DomainNameLabel $domName –Tag @{Name=”costCenter”;Value=”Sales”}

image

If you want a complete log of what has been denied:

Get-AzureRmLog | where {$_.OperationName -eq "Microsoft.Authorization/policies/deny/action"} 

This is great stuff. The portal doesn’t let you pick a tag from creating time, so you may need to leverage PowerShell for that. Another example is in regards of what kind of resources you want people to deploy. Often enough, groups will only work with Infrastructure elements (Compute, Storage,etc). You don’t want them to accidentally spin up a SQL Database or a Logic App. The policy below only allows for specific types of resources:

{
  "if" : {
    "not" : {
      "anyOf" : [
        {
          "field" : "type",
          "like" : "Microsoft.Resources/*"
        },
        {
          "field" : "type",
          "like" : "Microsoft.Compute/*"
        },
        {
          "field" : "type",
          "like" : "Microsoft.Storage/*"
        },
        {
          "field" : "type",
          "like" : "Microsoft.Network/*"
        }
      ]
    }
  },
  "then" : {
    "effect" : "deny"
  }
}

Let’s apply this policy (and first remove the previous one) and test creating something fancy in our resource group. First, removing:

Get-AzureRmPolicyAssignment -Name “tagPolicyAssignment” -Scope $RG.ResourceId| Remove-AzureRmPolicyAssignment -Scope $RG.ResourceId

($RG contains my resource group object).

You will get this confirmation dialog:

image

Say yes.

Now let’s add another policy (3) in this case.

$PolicyDef3=@”
{
  “if” : {
    “not” : {
      “anyOf” : [
        {
          “field” : “type”,
          “like” : “Microsoft.Resources/*”
        },
        {
          “field” : “type”,
          “like” : “Microsoft.Compute/*”
        },
        {
          “field” : “type”,
          “like” : “Microsoft.Storage/*”
        },
        {
          “field” : “type”,
          “like” : “Microsoft.Network/*”
        }
      ]
    }
  },
  “then” : {
    “effect” : “deny”
  }
}
“@
$policy3 = New-AzureRmPolicyDefinition -Name tagPolicyDefinition3 -Description “Policy to allow resource creation only certain objects” -Policy $PolicyDef3
New-AzureRmPolicyAssignment -Name ResourcePolicyAssignment -PolicyDefinition $policy3 -Scope $RG.ResourceId

Let’s try and add a Network security group:

image

All good:

image

Now, let’s try, say, a SQL Database.

image

Details:

image

And bam! Denied!

image

image

In a nutshell, combining RBAC and Azure Resource Manager Policies gives you a lot of control and ability to create (and enforce) governance over subscriptions, resources groups and resources.

Hope this helps!