I have seen an increasing number of users switching from using automation accounts to using virtual machine automation task templates (logic apps) for virtual machine stop/start automation.
This is not entirely surprising as this template is wizard driven and generally very straightforward to set up whereas configuring an automation account to trigger a script was never a smooth process in my opinion and prone to execution issues and troubleshooting.
These automation task templates although still technically marked as in preview simply create a logic app (which is not in preview) for you and the creation wizard helps you to configure the API connections and the configuration parameters. Nice and easy, right?
Well yes, but as a wise man once said “Don’t accept the defaults!”
A couple of examples of what I mean here are that you will likely want to have different stop/start schedules for the weekend. This requires going back into the logic app designer and modifying the task recurrence schedule.
More importantly, you really don’t want to use your own user account as the identity that triggers the logic app. This is the only option that you are presented with when creating these virtual machine automation tasks through the wizard.
User accounts should be used by humans only, they should not be used for automated tasks and will almost certainly have far too many permissions assigned.
You will also experience issues with these accounts when trying to be more security conscious with them. For example, if you have configured things like conditional access policies or privileged identity management then it’s very likely that the automation task will not have the required privileges all of the time and will therefore fail to perform the automation task at least on some occasions.
This is why it’s better to just not configure automation with user accounts at all.
The better choice is to always use either a service principal or a managed identity for your automation tasks.
For the use of logic apps, although still in preview at the time of writing I would recommend to use managed identities (MI) in the long term. There is no “password” for a managed identity so the MI itself cannot be directly compromised due to a credential leak.
Should I use a system or user-assigned managed identity?
I’m not sure that there’s a right or wrong answer here, however depending on what type of logic app you have you may not have a choice here. Consumption based logic apps support both types but you now also have the option of using a standard SKU logic app. This is a single-tenant logic app environment and is provisioned on a dedicated hosting plan within your tenant. This logic app type will only support system-assigned managed identities right now.
If you do have the choice, then I usually tend to favour using system-assigned MIs due to the fact there is virtually no management overhead. The MI shares the same lifecycle as the resource so if you delete the logic app then the system-assigned MI is also deleted which keeps everything nice and clean.
At scale however, you may find that you end up with a lot of managed identities, one for every logic app where you are using the automation task template feature as each logic app will have it’s own system-assigned MI. In fact, you may well have two logic apps and therefore two managed identities per VM as the automation templates create separate logic apps for start and stop tasks for the same virtual machine.
Instead, you could create a single user-assigned MI with permissions to execute automation tasks on all of your virtual machines, one identity to control them all.
The choice is yours!
Changing virtual machine automation task to use a managed identity
You first need to enable the managed identity on the logic app. Here you can choose whether to go with the system or user-assigned managed identity as already mentioned.
Once enabled, you need to assign permissions to the managed identity. You will need to set the role to Virtual Machine Contributor to provide enough permissions to be able to start or stop virtual machines.
You can scope this to the resource group where your virtual machine is located but if you are using a single user-assigned managed identity for all of your virtual machines then you will want to scope this to your entire subscription; assuming your VMs are not all in the same resource group of course.
With the managed identity created and permissions assigned, you can now go and edit your logic app through the logic app designer and click on the change connection link to change your connection from a user account to your managed identity.
Click on add new and then click connect with managed identity.
Give your new connection a name and click create.
Don’t forget to also click the save button in your logic app designer.
Test and verify
Make sure to test that your workflow works with the managed identity.
You can verify that the managed identity was used by checking the activity log or through the Azure Active Directory sign-in logs.
Finally, please remember that at the time of writing both virtual machine automation task templates as well as logic app support for managed identities are still in public preview.
azurealan.ie 