Issues authenticating with Azure Key Vault from Azure Automation

Background

As you may know, Microsoft is deprecating support for RunAs Accounts in Azure Automation by 30/9 2023.

Instead they recommend migrating to Managed Identities.

In my quest to migrate a customer from RunAs Accounts to MIs, I stumbled across an issue.

The issue

I had already followed MS recommendations regarding migration to Managed Identites, found here: Migrate from a Run As account to Managed identities | Microsoft Learn

In their documentation, they provided a simple code-snippet for authenticating with both a user-assigned and a system managed identity.

try
{
    "Logging in to Azure..."
    Connect-AzAccount -Identity
}
catch {
    Write-Error -Message $_.Exception
    throw $_.Exception
}

When you want to use a user-assigned MI you just add the parameter -AccountId followed by ClientId of the MI.

When I tried to authenticate with a user-assigned MI, I got this error message in Azure Automation:

ManagedIdentityCredential authentication failed: User assigned identity is currently not supported

Which made me believe that it was the Az-module that was not supporting user-assigned MIs.

After a bit of hair-pulling, I found this

The runbook that I was trying to migrate was a hybrid worker. So that explains that.

Then I tried to use the system-assigned MI instead. That got me further, but even though that I had added Azure RBAC permissions for the MI to the Key Vault I was trying to pull secrets from, I got a permission denied:

Operation returned an invalid status code ‘Forbidden’
Code: Forbidden
Message: The user, group or application ‘appid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;oid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;iss=https://sts.windows.net/tenantid’ does not have secrets get permission on key vault ‘VaultName;location=locationName’. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125287

The solution

Again, I was pulling my hair out. I did not understand why the RBAC permission didn’t apply.

…Until I read about Access Policies in Key Vault. Basically, they determine whether a given user, application or user group, can perform different operations on Key Vault secrets, keys, and certificates.

You can either use Azure RBAC to access the vault, OR use Vault Access Policies.

My assumption was that Azure RBAC automatically applies to Key Vault. It seems that the Azure RBAC functionality has been added lately, and that it is not on by default on existing Key Vaults. If you create a new KV, Azure RBAC is prechecked in the wizard nowdays:

However, since my Key Vault was using Vault Access Policy instead of Azure RBAC, I added permissions for my MI to the KV via Powershell:

Set-AzKeyVaultAccessPolicy -ServicePrincipalName "<ID of the MI>" -PermissionsToSecrets "Get" -VaultName "<VaultName>"

Voilá, that solved my problem!

Note that this can also be done via the portal. I could also just have changed the access method to Azure RBAC, that would have solved it as well.