Use Azure Policy to assign managed identities (preview)

Azure Policy helps enforce organizational standards and assess compliance at scale. Through its compliance dashboard, Azure policy provides an aggregated view that helps administrators evaluate the overall state of the environment. You have the ability to drill down to the per-resource, per-policy granularity. It also helps bring your resources to compliance through bulk remediation for existing resources and automatic remediation for new resources. Common use cases for Azure Policy include implementing governance for:

• Resource consistency
• Regulatory compliance
• Security
• Cost
• Management

Policy definitions for these common use cases are already available in your Azure environment to help you get started.

Azure Monitoring Agents require a managed identity on the monitored Azure Virtual Machines (VMs). This document describes the behavior of a built-in Azure Policy provided by Microsoft that helps ensure a managed identity, needed for these scenarios, is assigned to VMs at scale.

While using system-assigned managed identity is possible, when used at scale (for example, for all VMs in a subscription) it results in substantial number of identities created (and deleted) in Microsoft Entra ID. To avoid this churn of identities, it is recommended to use user-assigned managed identities, which can be created once and shared across multiple VMs.

Policy definition and details

• Policy for Virtual Machines
• Policy for Virtual Machine Scale Sets

When executed, the policy takes the following actions:

1. Create, if not exist, a new built-in user-assigned managed identity in the subscription and each Azure region based on the VMs that are in scope of the policy.
2. Once created, put a lock on the user-assigned managed identity so that it will not be accidentally deleted.
3. Assign the built-in user-assigned managed identity to Virtual Machines from the subscription and region based on the VMs that are in scope of the policy.

There are two scenarios to use the policy:

• Let the policy create and use a “built-in” user-assigned managed identity.
• Bring your own user-assigned managed identity.

The policy takes the following input parameters:

• Bring-Your-Own-UAMI? - Should the policy create, if not exist, a new user-assigned managed identity?
  • If set to true, then you must specify:
    • Name of the managed identity.
    • Resource group containing the managed identity.
  • If set to false, then no additional input is needed.
    • The policy will create the required user-assigned managed identity called “built-in-identity” in a resource group called “built-in-identity-rg".
• Restrict-Bring-Your-Own-UAMI-To-Subscription? - When the Bring-Your-Own-UAMI parameter is set to true, should the policy utilize a centralized user-assigned managed identity or utilize an identity for each subscription?
  • If set to true, then no additional input is needed.
    • The policy will use a user-assigned managed identity per subscription.
  • If set to false, the policy will utilize a single centralized user assigned managed identity that will be applied across all the subscriptions covered by the policy assignment. You must specify:
    • User Assigned Managed Identity Resource Id

Using the policy

Creating the policy assignment

The policy definition can be assigned to different scopes in Azure – at the management group subscription or a specific resource group. As policies need to be enforced all the time, the assignment operation is performed using a managed identity associated with the policy-assignment object. The policy assignment object supports both system-assigned and user-assigned managed identity. For example, Joe can create a user-assigned managed identity called PolicyAssignmentMI. The built-in policy creates a user-assigned managed identity in each subscription and in each region with resources that are in scope of the policy assignment. The user-assigned managed identities created by the policy has the following resourceId format:

/subscriptions/your-subscription-id/resourceGroups/built-in-identity-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/built-in-identity-{location}

For example:

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/built-in-identity-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/built-in-identity-eastus

Required authorization

For PolicyAssignmentMI managed identity to be able to assign the built-in policy across the specified scope, it needs the following permissions, expressed as an Azure RBAC (Azure role-based access control) Role Assignment:

As the policy assignment object must have this permission ahead of time, PolicyAssignmentMI cannot be a system-assigned managed identity for this scenario. The user performing the policy assignment task must pre-authorize PolicyAssignmentMI ahead of time with the above role assignments.

As you can see the resultant least privilege role required is “contributor” at the subscription scope.

Known issues

Possible race condition with another deployment that changes the identities assigned to a VM can result in unexpected results.

If there are two or more parallel deployments updating the same virtual machine and they all change the identity configuration of the virtual machine, then it is possible, under specific race conditions, that all expected identities will NOT be assigned to the machines. For example, if the policy in this document is updating the managed identities of a VM and at the same time another process is also making changes to the managed identities section, then it is not guaranteed that all the expected identities are properly assigned to the VM.

Next steps

• Deploy Azure Monitor Agent