Azure Resource Manager Policy to add cost center and owner tags

Azure Resource Manager (ARM) allows you to enforce organisational standards through the use of custom policies.  There are a number of things that you can do with ARM policies.  These range from restricting the size of virtual machines and the location they can be deployed, through to ensuring standardised naming conventions.

ARM Policies are made up of conditions, logical operators and effects.  Policies can be applied to a subscription, resource group or resource.

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

As it currently stands, if an ARM Policy is applied which requires specific ARM tags to present, deployment of resources via the Azure Portal is blocked by the ARM Policy.  The resource deployment blades in portal.azure.com do not allow the setting of tags as part of the deployment as such the ARM Policy stops the deployment.  For some customers this is not a problem as all resources are deployed using ARM templates and any template which does not have the right tags set will not be allowed to deploy. But for many customers ‘breaking’ the UI experience is really bad.

As ARM Policies have an effect of append as well as deny, a set of policies can be created to append default tags to resources as they are created, these can then be updated via the UI (or PowerShell or CLI).  This allows staff to continue using the UI for resource deployment but they will have to update the tags once the resource is provisioned.

To force all resources created in a resource group to have a default tag of ‘owner’ and ‘costcenter’ added (if not present) when the resource is being created, the following ARM Policies need to be created.

CostCenterTag.JSON

This Policy fires if tags are present for the resource but the costcenter tag is not present.  The policy appends the costcenter tag with a default value.

{
  "if": {
    "allOf": [
      {
        "field": "tags",
        "exists": "true"
      },
      {
        "field": "tags.costCenter",
        "exists": "false"
      }
    ]
  },
  "then": {
    "effect": "append",
    "details": [
      {
        "field": "tags.CostCenter",
        "value": "666"
      }
    ]
  }
}

OwnerTag.JSON

This Policy fires if tags are present for the resource but the owner tag is not present.  The policy appends the owner tag with a default value.

{
  "if": {
    "allof": [
      {
        "field": "tags",
        "exists": "true"
      },
      {
        "field": "tags.owner",
        "exists": "false"
      }
    ]
  },
  "then": {
    "effect": "append",
    "details": [
      {
        "field": "tags.owner",
        "value": "Daniel"
      }
    ]
  }
}
NoTagsPresent.JSON
This policy fires if the resource has no tags and adds the costcenter and owner tags with default values.
{
  "if": {
    "field": "tags",
    "exists": "false"
  },
  "then": {
    "effect": "append",
    "details": [
{
        "field": "tags",
        "value": {"costCenter":"666", "owner":"daniel"   }

      },
      
        ]
  }
}

All three policies need to be applied so that tags are added under the scenario that an ARM template is used that contains other tags and the scenario that a deployment is done via the UI or using an ARM template and no tags are specified .

These Policies and the PowerShell commands to deploy the policies can be downloaded from https://github.com/dbowbyes/ARM

A copy of the PowerShell script used to deploy the ARM Policies is included below.

$mysubscription = 
$myresourcegroup =


login-azurermaccount
Get-AzureRmSubscription
Select-AzureRmSubscription -SubscriptionId $mysubscription

$policy = New-AzureRmPolicyDefinition -Name tags-owner -Description "Policy to set owner tags" -Policy "tags-owner.json"
New-AzureRmPolicyAssignment -Name tags-owner -PolicyDefinition $policy -Scope /subscriptions/$mysubscription/resourceGroups/$myresourcegroup

$policy = New-AzureRmPolicyDefinition -Name tags-costcenter -Description "Policy to set costcenter" -Policy "tags-costcenter.json"
New-AzureRmPolicyAssignment -Name tags-costcenter -PolicyDefinition $policy -Scope /subscriptions/$mysubscription/resourceGroups/$myresourcegroup

$policy = New-AzureRmPolicyDefinition -Name tags-notags -Description "Policy to set costcenter" -Policy "tags-notags.json"
New-AzureRmPolicyAssignment -Name tags-notags -PolicyDefinition $policy -Scope /subscriptions/$mysubscription/resourceGroups/$myresourcegroup

The following command can be used to see what ARM Policies have been applied to a subscription or resource group

get-azureRMpolicyassignment -Scope /subscriptions/$mysubscription/resourceGroups/$myresourcegroup

More information and examples of ARM Policies can be found here.

Azure VNet Peering

VNet Peering has just been released in to public preview by Microsoft.  It allows VNets within the same region to communicate using the low latency, high bandwidth Azure backbone network .  Prior to VNet peering to allow communication between two VNet’s we had to setup VNet to VNet IKE connections which required VPN Gateways to be setup. These gateways cost money to run and inject potential throughput issues and other overheads inherent with traffic encapsulation.

Reading through the blog posts that Microsoft have released and having a play with VNet peering this evening there are a couple features that I really like:

  1. You can peer VNet’s across subscriptions and between ARM and ASM VNet’s
  2. You can control if the remote VNet can use your local gateway and if you want your VNet to use a remote VNet’s gateway
  3. All other networking features work with VNet peering, including UDR’s, Network Appliances, VPN Gateways and NSG’s
  4. VNet Peering can be setup even if VNet to VNet connections via gateways are in place. As soon as the VNet peering comes up it will be preferred over the VNet to VNet connection which allows it to be implemented with very little if any traffic impact.

VNetPeering

Microsoft have written some great blog articles on how to enable VNet peering, which can be managed via PowerShell as well as the Azure Portal.

https://azure.microsoft.com/en-us/documentation/articles/virtual-network-peering-overview/

One thing to note is that VNet peering needs to be enabled via PowerShell for each subscription that you want enable peering.  The PowerShell code below can be used to enable VNet peering for your subscription.

Login-AzureRmAccount
Get-AzureRmSubscription

Get-AzureRmSubscription -Subscriptionname "you sub name here" |Select-AzureRmSubscription

#register provider
Register-Azurermproviderfeature -FeatureName AllowVnetPeering -ProviderNamespace Microsoft.network
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

#show provider registration status
Get-AzureRmProviderFeature -FeatureName AllowVnetPeering -ProviderNamespace Microsoft.network

 

 


 

 

Azure – DevTest Labs

DevTestLab

One of the things about becoming an MVP is that you get notified about all sorts of interesting things coming in the world of Azure.  One new feature that caught my eye this week was Azure DevTest Labs, which is currently in preview.  Claude Remillard gave a great overview of DevTest Labs at the recent AzureCon event.

https://azure.microsoft.com/en-us/documentation/videos/azurecon-2015-introducing-azure-devtest-lab/

My interest in DevTest Labs (and the reason that I have registered for the preview) is the work the team has done to make it easy to spin up labs for testing purposes, they can be set to shutdown automatically when idle! (yay no more wasted spend!).

There are a couple of other functions that really caught my eye:

  • Ability to set quota’s for labs on machine sizes and spend plus usage monitoring so its easy to see if spend in the Lab is on track
  • Lab User security role which locks the user out of the rest of the Azure subscription and ensures they can only access the lab and its associated resources
  • Scheduled Lab shutdown (Scheduled Lab startup is coming)   — there is not point in my mind for paying for the running cost of machines that are not required or being used
  • Integration in to Visual Studio release pipeline so that code can easily be deployed to a Lab for testing

As well as Development teams I can see this being useful for Infrastructure teams.  One question I get asked  alot is how can we give our staff the ability to create a couple of VM’s in Azure but control the spend……Do we have to create a subscription for each of them?  I see DevTest Lab as solving this and allowing a single subscription to be used.  A customer can setup a Lab for each staff member with a quota attached, with the scheduled shutdown or shutdown on idle enabled compute costs would be hugely minimised.

If you are interested you can sign up for the private preview on the DevTest Labs page

DirSync & change password at log on

I have been playing around with Azure AD in preparation for speaking at TechED NZ this year; once I got DirSync up and running I found that each new account that I created in my local AD could not log on to MyApps.microsoft.com unless I reset its password.

This puzzled me for a couple of nights….What was I doing wrong ?

It turns I was doing nothing wrong, what I was experiencing was the correct behavior when “User must change password at next log on” flag is set.  This flag is set by default when creating a new User Account using ADAC.

Unlike your local AD where staff get prompted to reset their password after logging in; when accessing MyApps.Microsoft.com staff get a user name or password  incorrect and they can click on the link to reset their password.

It would be nice if there was some way that Azure AD could prompt and say your Administrator has requested that you reset your password before you can log in 🙂

Innovation Lead at Datacom NZ by day and MS Azure geek at night.  I also help run the Microsoft Wellington Infrastructure and Azure User group.