Tag Archives: ARM Policies

Azure Stack Policy Module for Azure

When you want to deploy your services across both Azure & Azure Stack, you need to make sure that both environments has the same resources and services available. Also the resources should be compatible with each other. The Azure Stack Policy module enables the same versioning and services that Azure Stack has in your Azure subscription. This will allow you to create a new Azure Policy that limits the available resources in your Azure environment to that of Azure Stack.

Let’s see how we can achieve this with PowerShell.

Installing the Policy Module

Apply the Policy

If you want to apply the default Azure Stack policy to your Azure subscription itself, you can use the below example.

Login-AzureRmAccount
$s = Select-AzureRmSubscription -SubscriptionName "<Azure Subscription Name>"
$policy = New-AzureRmPolicyDefinition -Name AzureStackPolicyDefinition -Policy (Get-AzsPolicy)
$subscriptionID = $s.Subscription.SubscriptionId
New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$subscriptionID

If you want to apply the policy into a particular resource group, you can execute the below snippet. This is useful when you have other Azure services running in the same Azure subscription which are not compatible with Azure Stack. Targeting a specific resource group to deploy the default Azure Stack policy will allow you to test apps that are developed for Azure Stack.

Login-AzureRmAccount
$rgName = '<resource group name>'
$s = Select-AzureRmSubscription -SubscriptionName "<Azure Subscription Name>"
$policy = New-AzureRmPolicyDefinition -Name AzureStackPolicyDefinition -Policy (Get-AzsPolicy)
New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$subscriptionID/resourceGroups/$rgName

Azure Resource Policies | Part 2

In my last post we discussed what Azure Resource Policies are and how it can help you to better manage your Azure deployments. Now it’s time to understand how to practically implement and use resource policies in Azure.

Control Virtual Machines sku in a resource group

In this example we are denying the creating VMs other than Standard A1 sku in a resource group by applying a custom resource policy.

First we create a resource group to apply this policy.

$ResourceGroup = New-AzureRmResourceGroup -Name protectedrg -Location “South East Asia”

Next we are going to define our security policy. This policy allows only Standard A1 VMs to be created when applied to a resource group.

$PolicyDefinition = New-AzureRmPolicyDefinition –Name vmLockPolicy -DisplayName vmLockPolicy -Description “Do not allow the creation of Virtual Machines” -Policy ‘{
“if”: {
“allOf”: [
{
“field”: “type”,
“equals”: “Microsoft.Compute/virtualMachines”
},
{
“not”: {
“field”: “Microsoft.Compute/virtualMachines/sku.name”,
“in”: [ “Standard_A1” ]
}
}
]
},
“then”: {
“effect”: “deny”
}
}’

Next we are going to assign the policy to our newly created resource group. First we are retrieving the subscription name and resource group name to which the custom policy to be assigned.

$Subscription = Get-AzureRmSubscription -SubscriptionName “MVP Personal”
$ResourceGroupName = $ResourceGroup.ResourceGroupName

Now we can assign the policy accordingly.

$AssignPolicy = New-AzureRmPolicyAssignment -Name vmLockPolicyAssignment -PolicyDefinition $PolicyDefinition -Scope /subscriptions/$Subscription/resourceGroups/$ResourceGroupName

Let’s try to create a virtual machine of DS1 v2 sku in the protectedrg resource group as below.

arm-policy-vm-creation-1 However the deployment activity fails as per our custom resource policy.

arm-policy-vm-creation-2

In the next post let’s discuss resource locking in Azure.

Azure Resource Policies | Part 1

Any data center should adhere to certain organizational compliance policies whether it is on-premises or cloud. If your organization is using Microsoft Azure and want your resources to adhere resource conventions and standards that govern the data center policy of your organization how would you do that? For an example you want to restrict person A to not to create VMs larger than Standard A2.  The answer would be to leverage custom resource policies and assigning them at the desired level, be it a subscription, resource group or an individual resource.

Is it same as RBAC?

No it isn’t. Role Based Access Controls in Azure is about actions a user or a group can perform while policies are about actions that can be applied at a resource level.  As an example RBAC sets different access levels in different scopes while policies can control what type of resources that can be provisioned or which locations those resources can be provisioned in an resource group/subscription. These two work together as in order to use a policy a user should be authenticated through RBAC.

Why do we need custom policies?

Imagine that you need to calculate chargeback for your Azure resources by team or department. Certain departments will need to have a limited consumption imposed and you need to charge the proper business unit at the end. Also if your organization wants to restrict what resource or where they are provisioned in Azure. For an example you want to impose a policy that allows user to create Standard A2 VMs only in West Europe region. Another good example is that you want to restrict creating load balancers in Azure for all the teams except the network team.

Policy Structure

As all ARM artifacts policies are also written in JSON format which contains a control structure. You need to specify a condition and what to perform when that condition is met simply like an IF THEN ELSE statement. There are two key components in a custom Azure resource policy.

Condition/Logical operators which contains a set of conditions which can be manipulated through a set of logical operators.

Effect which describes the action that will be performed when the condition is satisfied, either deny, append or audit.  If you create an audit effect it will trigger a warning event service log. As an example your policy can trigger an audit if someone creates a VM larger than Standard A2.

  • Deny generates an event in the audit log and fails the request
  • Audit generates an event in audit log but does not fail the request
  • Append adds the defined set of fields to the request

Following is the simple syntax for creating an Azure Resource policy.

{
“if” : {
<condition> | <logical operator>
},
“then” : {
“effect” : “deny | audit | append”
}
}

Evaluating policies

A policy will be evaluated at the time of resource creation or when a template deployment happens using a HTTP PUT request. If you are deploying a template, it will be evaluated during the creation of each resource in the template.

In the next post let’s discuss some practical use cases of using Azure resource policies to regulate your resources.