[Feature Request]: Custom Policy Role Scopes

[Greg-Court]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Is your feature request related to a problem?

[Examples] Override Module Role Assignments provides a great guide on how to customise policy role assignments. However, it would be very helpful if we could specify different scopes for each role assignment, especially when dealing with resources across different subscriptions or management groups.

Describe the solution you'd like

I propose enhancing the custom_policy_roles variable to support a more flexible structure that allows specifying both the role definition ID and the scope for each role assignment. This would enable users to assign roles at different scopes for the same policy, which is particularly useful in cross-subscription scenarios.

A practical example of where this enhanced functionality would be beneficial is in the deployment of Azure Monitor's Data Collection Rules (DCRs). Consider the following scenario:

A policy is assigned at the landing zones management group level to associate VMs with a Data Collection Rule.
The VMs are in one subscription (e.g., a corp subscription).
The Data Collection Rule itself is in a different subscription (e.g., management subscription).

In this case, the policy's system assigned managed identity needs different permissions at different scopes:

• 'Microsoft.Insights/dataCollectionRuleAssociations/write' permission on the VM's subscription
• 'Microsoft.Insights/dataCollectionRules/read' permission on the subscription containing the DCR

With the current implementation, we can only assign roles at the policy assignment scope (the landing zones management group). This doesn't provide the necessary granular permissions for cross-subscription scenarios. The proposed enhancement would allow us to assign the required roles at the appropriate scopes, see below.

Current structure for custom_policy_roles:

  custom_policy_roles = {
    "/providers/Microsoft.Authorization/policySetDefinitions/a169a624-5599-4385-a696-c8d643089fab" = [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
      "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
    ],
    "/providers/Microsoft.Authorization/policyDefinitions/f4c68484-132f-41f9-9b6d-3e4b1cb55036" = [
      "/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635"
    ]
  }

Proposed new structure for custom_policy_roles:

custom_policy_roles = {
  "policy_definition_id" = [
    {
      role_definition_id = "role_definition_id_1"
      scope              = "scope_1"
    },
    {
      role_definition_id = "role_definition_id_2"
      scope              = "scope_2"
    }
  ]
}

Example implementation:

custom_policy_roles = {
  "/providers/Microsoft.Authorization/policyDefinitions/eab1f514-22e3-42e3-9a1f-e1dc9199355c" = [
    {
      role_definition_id = "/providers/Microsoft.Authorization/roleDefinitions/749f88d5-cbae-40b8-bcfc-e573ddc772fa"
      scope              = "/providers/Microsoft.Management/managementGroups/contoso-landing-zones"
    },
    {
      role_definition_id = "/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05"
      scope              = "/subscriptions/00000000-0000-0000-0000-000000000000"
    },
    {
      role_definition_id = "/providers/Microsoft.Authorization/roleDefinitions/92aaf0da-9dab-42b6-94a3-d43ce8d16293"
      scope              = "/subscriptions/11111111-1111-1111-1111-111111111111"
    }
  ]
}