Azure Runbooks – Migrate from Azure Run as Accounts to Managed Identity soon!

Microsoft is always changing whether we like it or not. One of the more recent changes made is on using a Managed Identity instead of an Azure Run as Account inside of an Automation Account. Why the change? What are the benefits of using an identity? How do I ‘migrate’ over to using a managed identity and what changes do I make?

Why the change?

When you would create an Automation Account it would come with the option to create an Azure Run as Account, which would be used in your runbooks to authenticate against your Azure tenant and therefore allowing you to manage your resources programmatically using PowerShell or Python scripting languages. These accounts by default would come with the Contributor role over the subscription. You would also have to make sure to renew the certificate once it expired. Otherwise, if you didn’t pay attention or have some other product in use to monitor this, it would expire on you and your runbooks would fail.

Thats why Microsoft began pushing for managed identities. Where it is now Azure’s responsibility to register the app in the backend, create a service principal, generate a certificate and do all of that stuff for you. With Managed Identity all you have to worry about is enabling it for your service and assigning it permissions following the least privilege model.

What are the benefits of using a Managed Identity?

Less overhead. Simplifies management.
Free.
Simpler code.

Migration

Let’s start off with all the components of an Azure Run as Account within an Automation Account and any related messages you may see.

When you open your Automation Account, you will most likely see a notification about the retirement of the Azure Run as account which looks like this:

Now, there are 3 components related to the Azure Run as Account. They can be found under Connections, Certificate and Run as accounts (retiring soon) options on the left. The connections section contains metadate about the service principal such as the application ID, tenant ID, and thumbprint which can be used to authenticate to your tenant via runbook. Certificate contains the certificate details also used to authenticate. And of course, the Run as Account (retiring soon) contains properties about the account. Once we enable the identity, assign it permissions, and successfully use it within a runbook, then we can delete the account and it will delete the other related parts too.

The first step in migrating is to enable the system assigned managed identity. We can do this simply by going to Automation Account > Account Settings > Identity > System assigned > Status > On > Save > Yes.

Azure then quickly registers it with your Azure AD (Entra ID now I think) tenant. The next step is to assign it permissions.

To add the permissions, you will see the permissions section below after you create the identity.

Click on Azure role assignments. From here, you can click on + Add Role assignment towards the top left corner.

Once opened, you will see Scope, Subscription, and Role. To keep it simple, and working exactly as before, for Scope select Subscription, for Subscription select the correct subscription, and then for Role select Contributor. Then Save. This will keep permissions exactly the same as before.

Of course, when using a Managed Identity, I recommend following the least privilege model and if possible, only using specific roles/permissions instead of the Contributor role. After you click on Save, give it a few minutes for the permissions to properly propagate and then you will see it under Azure Role Assignments after.

With the permissions assigned now we have to make the changes on the runbook side. So, let’s take a look at a simple runbook for this. In this runbook called MigrationDemo we are just going to include the authentication process only. Since in your runbook, that is the only thing you will need to change. The runbook looks like this:

So, in your runbook, you will most likely have a section just like this using Az modules plus other logic. I don’t really care about the other logic, since our focus is in updating the authentication process itself from using Azure Run as accounts to using managed identity instead. The example above will actually be swapped out for this instead:

Try
{
    Disable-AzContextAutosave -Scope Process
    "Logging in to Azure..."
    Connect-AzAccount -Identity
    $AzureContext = Set-AzContext -SubscriptionId "###################"
}
catch {
    Write-Error -Message $_.Exception
    throw $_.Exception
}

If you are using AzureRM based modules, then use this instead:

try
{
    Disable-AzureRmContextAutosave -Scope Process
    "Logging in to Azure..."
    Connect-AzureRmAccount -Identity
    $AzureContext = Select-AzureRmSubscription -SubscriptionId "###################"
}
catch {
    Write-Error -Message $_.Exception
    throw $_.Exception
}

Note 1: I would not just delete the old code immediately. You can test the new code in 2 ways. 1.) Comment out the previous code, then add the new logic and test. 2.) Create another runbook with the same exact code + the changes, and then test with that first. Once you confirm it works, then push the changes to production runbooks.

Note 2: Make sure to include your subscription ID with the new code.

Note 3: If you don’t know what the code is doing, don’t just run it cause I said so. Look up the cmdlets in Microsoft Docs and read how it works and what it does.

Note 4: Fine here you go:

When testing this new code in your test pane, output should look like this + whatever else you are doing within your runbook:

There ya go. Now you successfully enabled the identity, assigned it permissions exactly as the Azure Run as Account, made changes to your runbook, tested, and verified it worked. Thats the basic migration process.

Now you can remove the Azure Run as Account by going to Automation Account > Account Settings > Run as Account (retiring soon) > select the account.