Zero Trust - Modify Azure Policy Role Definitions

Zero Trust - Modify Azure Policy Role Definitions

Modify the Role Definition of an Azure Policy to apply the Principal of Least Privilege. 

There is built-in Azure Policies that use a role definition with substantial rights such as a Subscription Contributor. In some cases, you may not need or want those rights assigned to the managed identity that will perform actions on behalf of the policy. In this blog, I'll share how to modify an Azure policy role definition to reduce the permissions of the managed identity and thus, apply the principal of least privilege which is one of three key tenets in the Microsoft zero trust framework. 

In this example, we will use the built-in Azure policy, "Inherit a tag from the subscription". This policy is useful if you want a resource tag that is applied to a subscription, to be applied to the resources that are deployed within the subscription.

Identify the default role definition

First you must identify the role definition used by the policy. Below is a snippet of what the default policy looks like. I want you to notice two things.

• It has a Modify effect. Modify is used to add, update, or remove properties or tags on a subscription or resource during creation or update. In other words, the policy may do things on your behalf. 

• It is using the role definition of "b24988ac-6180-42a0-ab88-20f7382dd24c" which is the unique ID of the Subscription Contributor role. Unique IDs is like a primary key for an RBAC roles and their consistent throughout Azure. How do I know what role a unique ID maps to? There are several ways, one way is to view\search the unique IDs and role mappings here.

Understand what the policy will do

If you want to modify the role definition, you must first identify what operations the policy will perform. This is required so that you can identify if there are other RBAC roles in which you can use with the policy. 

Below is another snippet of the same policy. 

• The policy applies the operation addOrReplace which adds the defined tag and value to the resource, even if the property or tag already exists with a different value.

• The supplied policy parameter tagName, which should be configured on the targeted Azure Subscription, is added or updated to all applicable (e.g., non-indexed) resources with the value assigned to the subscription. (Indexed vs. non-indexed resources is outside the scope of this article, but if you are curious what it means and the implications, look here).

Once you've identified what actions the policy will perform you can identify what RBAC role(s) can be leveraged for the policy role definition. If you are curious what the ever-growing built-in roles are and what permissions they have, look here. In this case, the subscription contributor may be replaced with the tag contributor. The tag contributor lets you manage tags on entities, without providing access to the entities themselves. That sounds perfect! Curious to learn more about tag contributor role? Look here. 

Updating the role definition

Once you know the change roleDefinition change you want to make, it's time to update the policy. To update a policy role definition, I suggest you duplicate the policy, and then modify the policy with the new role definition. Generally speaking, duplicating the original policy definition helps ensure you have the original to refer back to in the event things go awry with any policy changes to the built-in policy set.

• To duplicate the policy, locate the policy and click "duplicate definition"

• Update the required policy parameters (location, name, description, category, etc...) and when you get to the role definition field, select the appropriate role(s). In this case, we will select "Tag Contributor". Note, if you don't see a place to update the roleDefinition, it's likely because the policy is not capable of performing any changes on your behalf (e.g. Audit).

• Once you select the tag Contributor role, you may notice that two roles now appear in the policy, the default role (subscription contributor) and the newly added role (tag contributor). This should tell you that a roleDefinition may be comprised of one or more RBAC roles. However, in our case, we want the subscription contributor role removed. 

• In order to remove the subscription contributor role either locate and uncheck the role in the drop-down menu or remove that line of code from the policy. Unchecking the role is a safer operation to ensure there are no syntax errors in the policy JSON. In the end it should look like this. Notice the Tag Contributor unique ID trail "4a9ae827-6dc8-4573-8ac7-8239d42aa03f". 

Now click save. It's time to test applying the new policy!

Note, policies such as this require a remediation task which creates the managed identity with permissions as defined in the roleDefinition. In this scenario, you should see the new managed identity, with the associated rbac role assigned to the subscription scope. 

Summary

That's it! Built-in Azure Policies come with default role definitions. Those role definitions may be over permissioned. If you want to adhere to a zero-trust security model and apply the principal of least privilege, modify applicable Azure policy role definitions with new rbac roles as demonstrated in this blog. 

I hope you found this helpful!