Initiative assignments require roleDefinitionIds of member policies whose effect is hardcoded to AuditIfNotExists — over-grants data-plane roles the assignment can never use

[ThojoUno]

Describe the bug

When building the roles plan for a policy set (initiative) assignment, Build-DeploymentPlans computes the assignment identity's required roles as the union of roleDefinitionIds across every member policy, without considering each member's effective effect. Members whose effect is hardcoded in the initiative to AuditIfNotExists (or Disabled/Audit/Deny — effects that never deploy anything) still contribute their roleDefinitionIds to the assignment's required role assignments.

The result is standing role grants — including data-plane roles — at the assignment scope (often an intermediate-root management group) for capabilities the assignment can structurally never exercise.

Steps to reproduce

1. Assign the built-in Microsoft Cloud Security Benchmark v2 initiative (/providers/Microsoft.Authorization/policySetDefinitions/e3ec7e09-768c-4b64-882c-fcada3772047, definitionVersion: 1.*.*-preview) at a management group via an EPAC assignment file.
2. Run Build-DeploymentPlans.
3. Inspect roles-plan.json.

Actual: the plan adds Azure Event Hubs Data Owner (f526a384-b230-433a-b45c-95f59c4a2dec) for the assignment MI at the MG scope:

{
  "scope": "/providers/Microsoft.Management/managementGroups/<root>",
  "roleDisplayName": "Azure Event Hubs Data Owner",
  "properties": {
    "roleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/f526a384-b230-433a-b45c-95f59c4a2dec",
    "description": "Policy Assignment '.../Deploy-MCSB2-Monitoring': Role Assignment required by Policy, ..."
  }
}

Expected: no Event Hubs Data Owner grant. The only members of MCSB v2 that list that role are the 22 "Enable logging by category group for … to Event Hub" policies (Azure Firewalls, App Gateways, VNets, NSGs, Bastions, Load Balancers, Public IPs, ExpressRoute, Front Door/CDN, VPN/P2S gateways, Traffic Manager, Network Managers, …), and the initiative hardcodes every one of them to AuditIfNotExists (literal value in the member's parameters.effect.value, not a parameter reference — verifiable via az policy set-definition show --name e3ec7e09-768c-4b64-882c-fcada3772047). None of these members can ever run a deployment, so the identity never needs the role.

Root cause

In Build-DeploymentPlans.ps1 (module v11.5.5, same on main), the policy-set role map is built by unioning member roles with no effect check:

# Calculate roleDefinitionIds for built-in and inherited PolicySets
$readOnlyPolicySetDefinitions = $deployedPolicyResources.policysetdefinitions.readOnly
foreach ($id in $readOnlyPolicySetDefinitions.Keys) {
    $policySetProperties = Get-PolicyResourceProperties -PolicyResource $readOnlyPolicySetDefinitions.$id
    $roleIds = @{}
    foreach ($policyDefinition in $policySetProperties.policyDefinitions) {
        $policyId = $policyDefinition.policyDefinitionId
        if ($policyRoleIds.ContainsKey($policyId)) {
            $addRoleDefinitionIds = $PolicyRoleIds.$policyId
            foreach ($roleDefinitionId in $addRoleDefinitionIds) {
                $roleIds[$roleDefinitionId] = "added"
            }
        }
    }
    ...
}

The same union pattern exists in Build-PolicySetPolicyDefinitionIds.ps1 (repo-declared policy sets) and the Build-Hydration* mirrors. Build-AssignmentDefinitionAtLeaf.ps1 then consumes the pre-computed union verbatim for requiredRoleAssignments.

Note that $policyDefinition in the loop above already carries the member's parameters — including the hardcoded effect literal — so the information needed to filter is in scope at the defect site.

Proposed fix

Skip a member's roleDefinitionIds when its effect can never resolve to DeployIfNotExists, Modify, or Manual:

• the member's parameters.effect.value is a literal Audit / AuditIfNotExists / Disabled / Deny (the MCSB v2 case), or
• the effect is a parameter reference whose initiative-level parameter has allowedValues that exclude every deploying effect.

Where the effect is parameterizable and could flip to a deploying effect at assignment time, keep today's conservative union — the over-grant is only provable in the statically-resolvable case, and this keeps the change small and safe. (A fuller fix could resolve effective effects against assignment parameters at leaf-build time, but the static filter removes the concrete harm without a refactor.)

Happy to submit a PR along these lines if the approach is acceptable.

Why this matters

• The grant is a data-plane owner role at MG scope (every Event Hub namespace under the root), held by an identity that can never use it. This is exactly what customer least-privilege / security reviews flag, and it must be explained away on every review.
• Deployment SPs constrained by ABAC conditions on roleDefinitionIds (the delegation-constraint pattern) must allow-list roles nothing uses, widening what the SP itself may grant.
• MCSB v2 makes this newly visible (large initiative, many audit-pinned members with data-plane roles), and its adoption is spreading through ALZ.

Ecosystem corroboration

• ALZ-Bicep, which hand-curates each assignment's role list instead of computing it, added its Deploy-MCSB2-Monitoring module in feat: Add MCSB policy assignment and notScopes support ALZ-Bicep#1139 granting only Cognitive Services OpenAI Contributor, Cognitive Services Contributor, and Azure Connected Machine Resource Administrator — no Event Hubs Data Owner. The curated reference behavior for the same initiative omits the role this union demands.
• The ALZ Terraform accelerator's role calculator is independently seeing MCSB-v2-triggered defects in the same subsystem (Resolve policy definition versions to the version the assignment actually runs alzlib#248, [Bug]: policy_role_assignments ignores definitionVersion when resolving policy set definitions, causing spurious role assignment errors on upstream version bumps Azure-Landing-Zones#4190 — version-resolution rather than effect-filtering, but the same "computed MI role grants for initiative assignments" surface).

Environment

• EnterprisePolicyAsCode 11.5.5 (behavior verified in module source; union code unchanged on main)
• PowerShell 7.4 / Azure DevOps hosted agents and local
• Repro initiative: built-in MCSB v2 e3ec7e09-768c-4b64-882c-fcada3772047 @ 1.*.*-preview

[anwather]

Thanks for the detailed repro and information, will take a look at this.

[anwather]

Joe Thompson (@ThojoUno) - Ive created a fix for this - currently in the anwather-scaffold-issue-1393-repro branch. Are you able to do some testing? You should see a number of roles removed by EPAC. This MCSB v2 policy is a bit of a unique one in that it is the only policy set that utilises this hardcoding in the effect. I've also tested overriding the hardcoded effect using an override for policyEffect and confirmed this will add the proper roles based on the definitions/effect.

[ThojoUno]

TD;LR - Yes the fix worked! thank you for the quick turnaround!

Tested anwather-scaffold-issue-1393-repro at 4e2c798 against a live ALZ management group (11 MGs, 5 subscriptions, 89 managed assignments, 47 of them with an identity). Built the module from the branch and ran Build-DeploymentPlans three times so the two fixes could be looked at separately:

Pass | Module | filterRoleAssignmentsByEffect | Role plan -- | -- | -- | -- C | 11.5.5 (PSGallery) | n/a | 117 added / 81 removed B | branch | false | 117 added / 81 removed A | branch | default (true) | 111 added / 82 removed

Every dropped role is contributed exclusively by members pinned to a non-deploying effect, and Log Analytics Contributor survives on the strength of the single member that doesn't pin its effect. That lines up with your 8 → 1 result.

One data point on the version resolution that may be worth a doc line. This assignment pins definitionVersion: "1.*.*-preview", and MCSB v2 publishes both pre-release (1.0.0-preview … 1.3.0-preview) and stable (1.4.0 … 1.7.0). Get-PolicySetVersionedDetails treats the -preview suffix as "also consider pre-releases" and then takes the highest match overall, so it resolves to 1.7.0, not 1.3.0-preview. I checked that against ARM — GET <assignmentId>?api-version=2025-03-01&$expand=EffectiveDefinitionVersion reports effectiveDefinitionVersion: 1.7.0 — so EPAC and Azure agree and the behaviour is right.

Flagging it only because the docstring ("opts the assignment in to pre-release versions of the matching line") can be read as selecting the highest pre-release, which for this set would be 1.3.0-preview. Per your validation matrix a 1.3.x resolution retains the full 7-role union, so under that reading the filter would appear to silently no-op for anyone pinning this way. It doesn't — but making "highest match, pre-releases included" explicit in the docs would remove the ambiguity.

Happy to run more scenarios if useful; the policyEffect override path is the obvious next one from here.

[anwather]

Ok good - I did test the policyEffect override and it added the roles when changed to DeployIfNotExists but would also welcome if you want to test. Then I can go and publish.