Using Managed Identities in Azure Automation Accounts (preview)

This post has been republished via RSS; it originally appeared at: ITOps Talk Blog articles.

Whether it's to repeat common tasks or to automatically respond to a trigger, IT Pros look to automation to help streamline their work and improve their response times. In Azure, runbooks stored in Azure Automation accounts need to use credentials of an identity that they will run their actions as, if they are acting on a Azure resource. Azure Resource Manager checks that identity against to ensure it has permission to the resource before the actions are executed. Lets look at the new managed identities for Azure Automation (preview) and how they're better than the previous Run As accounts.

Run As accounts

Previously, we've used an Azure Automation "Run As" account for this execution identity. When you create an Azure Automation Run As account, it creates:

An Azure AD application with a self-signed certificate
A service principal account in Azure Active Directory for that application
And assigns the Contributor role to that service principal account in your subscription.
It also creates an Automation certificate asset to hold the certificate's private key, and an Automation connection asset which holds the application ID, tenant ID, subscription ID and certificate thumbprint.

That's a bit of complexity there, all to provide a secure identity. Also, that self-signed certificate will expire one year after creation and will need to be renewed.

System-assigned Managed Identity

Now in preview, Azure Automation supports using a system-assigned managed identity instead. This managed identity works with any Azure service that supports AD authentication and can be used in Hybrid jobs on Azure and non-Azure VMs with the Hybrid Runbook Worker. It removes the need for renewing certificates and you dont need to specify the Run As connection object in your runbook code.

Enabling managed identity in an Azure Automation account

In an existing automation account, in the Account Settings section you'll find the Identity blade and the option to turn on a system assigned identity.
Adding a system-assigned managed identity to your Azure Automation account - Identity blade inside the Azure Portal

Once created, it will show the managed identity's Object ID and you can add role assignments at the subscription or resource group level, or to key vault, storage or SQL
Azure Automation account enabled with a system-assigned managed identity

Now that your managed identity has been created and has a role that allows it to access your target resources, you can update your runbooks to use the Connect-AzAccount PowerShell cmdlet to call the managed identity:

Connect-AzAccount -Identity

View more sample runbooks here using managed identity.

Feedback

As always, we love your feedback but especially for features in preview as we seek to improve them. What do you think? Is this a better way of providing your automation runbooks with an identity? Would you change over your existing Azure Automation accounts? Let us know in the comments!