A common problem that is usually seen from the field when deploying an Azure Policy with the effect Modify or DeployIfNotExist is that the remediation task actually never runs, whether for existing resources or new resources.
This confusion is because there were no warnings or errors during the assignment of the Azure Policy. Let's look at this simple scenario:
Scenario:
- A user is creating a policy assignment to inherit a tag to resources if the tag is missing with the policy effect of Modify.
- This policy is applied at the Resource group level.
- The same user is having contributor role on the Resource Group level.
- The RoleDefinition in the policy template has the contributor or tag contributor role.
While creating the policy assignment there will be no warnings at all related to missing roles or permissions for the remediation task.
When the evaluation starts and you go back to the policy assignment you will see this new warning:
Why did that happen?
As explained in this Microsoft documentation:
"Contributor may trigger resource remediation, but can't create or update definitions and assignments. User Access Administrator is necessary to grant the managed identity on deployIfNotExists or modify assignments necessary permissions. All policy objects will be readable to all roles over the scope"
It simply means that although the user has required permissions to create the Azure Policy with associated remediation task identity in Azure Active Directory, the user does not have permissions to assign the newly created identity the required permissions at the assignment scope of the policy hence the remediation task will never get triggered. This is because the user has only a contributor role in this scenario.
This happens by design and is to prevent any user from remediating or altering resources just by having Azure Policy creation permissions.
How to move forward?
This scenario represents a good use case for using a User-assigned managed identity instead of the default policy system managed identity. It is often the case that there are teams of individuals who are deploying lots of Azure Policies and maintaining them on a daily basis and here lies the best practice of using a User-assigned managed identity in order to have only one single managed identity be associated across multiple Azure Policies, which makes the administrative overhead much easier and at the same time makes it easy to track and monitor the usage of these user-assigned managed identities, as opposed to using the classic way of having one system managed identity for every Azure Policy with Modify or DeployIfNotExist policy effect.
Then once the user-assigned managed identity has been created still it needs to be assigned required permissions at the right scope so that all associated remediation tasks would run smoothly with no errors.
More information could be found here in this Microsoft document on sample scenarios on which user-assigned managed identity would be a good option.
Microsoft
