Deploying an Automation Account with a user-assigned managed identity
Creating an Azure Automation Account with User-Assigned Managed Identity using Terraform
I’m early in a career as a DevOps engineer, mostly using Azure and Terraform and one of the first hurdles I encountered was having to create an Azure Automation Account with User-assigned Managed Identities from Terraform. (Jan 2022)(Note: as of Feb 2022 Terraform now allows you to create an automation account with a managed identity so if you are able to use the latest versions of Azurerm this post is outdated.)
Sounds easy. That’s why they probably gave that to me!
The background to this is that we need to create an Automation Account to start and stop virtual machines on a schedule. The obvious way to do this, and currently the most common, is via a runbook and using a ‘Run As’ account. However, Microsoft suggest that the best way to do this going forward is to use a managed identity, and it certainly seems like it may quite easy and more secure. The current “Start/Stop VM” feature is being deprecated in May 2022 and so knowing that the current option is going and the new one won’t be available until then, we decided to stick with tried and tested Runbooks, but to use a managed identity.
As of December 2021/ January 2022 the functionality to create an Automation Account that uses Managed Identities is not available from Terraform and Microsoft:
https://github.com/hashicorp/terraform-provider-azurerm/issues/11503
So now that we know it can’t be done, how do we do it? (Cue theme tune from the movie ‘Convoy’!)
My solution, the obvious one, was to use an ARM template. Your mileage may vary in how useful you find the following, but this is the information I needed a week or two ago! (All code for this short series is available here: https://github.com/tommakesmusic/medium_blog/tree/main/managed-id-ARM NOTE: this code is not ready for a production environment and is provided for your entertainment and education only!)
The accepted wisdom is that using Terraform to deploy ARM Templates can be messy and not always as reliable or successful as one would hope. However, Hashicorp has recently changed how the ‘Azurerm’ provider deploys ARM templates :
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/template_deployment
Knowing this, I thought I would give it a go, for practical and educational reasons. I decided that I would create an ARM template that was small and focussed and would only do the single thing I need it to do — a good philosophy, I think.
Ok, so on with the Terraform script. (I’m going to assume you know the very basics of Terraform and so will leave out describing the setup, variables, locals etc.) My plan was to deploy this via Azure DevOps pipelines so all has been written with this in mind.
Firstly, we need to create the managed identity. The system-assigned managed identity is simpler to set up but probably more awkward to reference for future infrastructure deployment needs, and in the case of the project I’m working on, we need to be able to have this in ‘Human-readable’ form. Here is the very straightforward code to create the user-assigned managed identity, pretty much straight from the ‘Azurerm’ documentation:
When you create the identity it is useless until you assign a role to it. The role sets the level of control the automation account will have. Be very careful about what scope and permissions you give it but you will need to give sufficient privilege to allow it to do the tasks required in your Runbooks, otherwise it is useless. Warning: only give it what is needed. Having over-powerful automations could lead to problems! Again, this code is almost straight from the documentation:
Now that we have the User-Assigned System Managed Identity, we need to create the Automation Account that will use it. This is the new terraform resource to deploy a template, again almost straight from the demo code:
One of the key things to note here is the “deployment_mode”. This can seriously mess up your day if you use the wrong value. If you use “Incremental” the ARM template will ADD to any existing infrastructure, but if you choose “Complete” it will behave like it has ALL the infrastructure you need and can remove existing resources. Since this is a simple ARM template to deploy a single resource, make sure to use “Incremental” for this value. For the speed and ease of debugging, I have placed the ARM template file in the same directory as the main.tf file. If you want to reference a different file/location you will need to update this. This will be caught at the validate/plan check anyway.
Next is a snippet of the ARM template I used to create the Automation Account. You must make sure that the parameters match exactly between the resource code in the terraform and the JSON of the ARM template. Any typos here will cause a lot of frustration. The Automation Account and Managed Identity section is just a couple of lines:
When you run the code at this stage, you will create the managed identity, give it a role and create the automation account. It is good to test things at this stage, just to check that it deploys correctly and you have no small errors etc. The infrastructure is not very useful at this point, however. Along with the code above you will need to create resources for the runbook, the schedule and the ‘schedule_job’ that links the runbook and the schedule together. That will be part two of this small series.
This infrastructure has worked reliably for me for a while now, and I hope it is of use to somebody, but we know how quickly things change and it may have a limited lifespan of use. As Microsoft update their Azure SDK and release the new “Start/Stop VM” V2 into the wild it may be that we update how we do this, but in Jan/Feb 2022 this has worked for us.
For Part two we will look at how the Runbook makes use of the managed identity.
