Using Managed Identities in Azure Automation Accounts (preview)

[Sonia Cuff]

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:

1. An Azure AD application with a self-signed certificate
2. A service principal account in Azure Active Directory for that application
3. And assigns the Contributor role to that service principal account in your subscription.
4. 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!

Learn more:

Azure Automation account authentication overview

Manage an Azure Automation Run As account

Manage runbooks in Azure Automation

Enable a managed identity for your Azure Automation account (preview)

What are managed identities for Azure resources?

[MartijnVerheijen]

It is great that Azure Automation has now the ability to leverage a System Managed Identity.

I do have two questions.

I found examples on how to connect the AZ and AzureAD modules but I was wondering how to connect to MSGraph by using the Intune Powershell SDK using the SMI.

Is this possible at the moment and if so how would I do that?

And is there an estimated ETA on User Managed Identity support?

Thanks again.

Martijn Verheijen

[Santosh Killekar]

Its really great to see the managed identities can be used for Azure Automation. Could you please also suggest the steps for providing the API access and Role assignment for Managed Identities using PowerShell?  Will this be only through PowerShell or through GUI in later releases? 

[Dean Gross]

@Sonia Cuff Can these be used with O365 services?

[SocInABox]

What is the 'Get' command to see the assigned roles for your managed identity?

I would have thought Get-AzureAdServiceAppRoleAssignment would work, but it's not returning anything.

I'm using managed identities with Logic Apps using the playbooks in GitHub, eg:

$MIGuid = "<enter your MIGuid here>"
$MI = Get-AzureADServicePrincipal -ObjectId $MIGuid
$MDEAppId = "fc780465-2017-40d4-a0c5-307022471b92"
$PermissionName = "Machine.Read.All"
$MDEServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$MDEAppId'"
# Get the Permission
$AppRole = $MDEServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}
# Use the Permission Id and assign it to the Managed IDentity
New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId -ResourceId $MDEServicePrincipal.ObjectId -Id $AppRole.Id

I want to validate the permissions that were assigned to the managed identity above, using powershell.

Thanks!

[Tadas Burovas]

How this could be used for Automation account and Teams powershell?  

[bart vermeersch]

Can the managed identity of the Automation account also be used within the DSC functionality (to read from a keyvault)?

[bart vermeersch]

Ok, it can :D