Summary
When EPAC calculates the roleDefinitionIds required by a Policy Set assignment's Managed Identity, it uses the latest version of the Policy Set as returned by ARM, rather than the version the assignment pins via definitionVersion.
Impact
If a member Policy's contribution to the role union differs between the pinned version and the latest version, the calculated roles do not match what the running assignment actually needs:
- A member which deploys in the pinned version but not in the latest version has its role omitted, so remediation fails at runtime with an authorization error.
- A member which deploys only in the latest version has its role granted unnecessarily.
The failure mode is silent. Nothing errors at plan or deploy time; the only symptom is a remediation task failing later.
Interaction with filterRoleAssignmentsByEffect
This defect is pre-existing and independent, but it is the main reason the new filterRoleAssignmentsByEffect setting is opt-in rather than default-on. That filter removes roles contributed only by members hard-coded to a non-deploying effect. Because the member effects are read from the latest version, a member which is DeployIfNotExists in the pinned version but AuditIfNotExists in the latest version would have its role removed while the running assignment still requires it.
With this defect fixed, the filter becomes safe by construction and defaulting it to true can be reconsidered.
Related
Same family of problem as Azure/alzlib#248 and Azure/Azure-Landing-Zones#4190.
Suggested fix
Resolve the Policy Set definition at the assignment's pinned definitionVersion when building policyRoleIds and the policy set details used for the role calculation, falling back to the latest version only when no version is pinned.
Summary
When EPAC calculates the
roleDefinitionIdsrequired by a Policy Set assignment's Managed Identity, it uses the latest version of the Policy Set as returned by ARM, rather than the version the assignment pins viadefinitionVersion.Impact
If a member Policy's contribution to the role union differs between the pinned version and the latest version, the calculated roles do not match what the running assignment actually needs:
The failure mode is silent. Nothing errors at plan or deploy time; the only symptom is a remediation task failing later.
Interaction with
filterRoleAssignmentsByEffectThis defect is pre-existing and independent, but it is the main reason the new
filterRoleAssignmentsByEffectsetting is opt-in rather than default-on. That filter removes roles contributed only by members hard-coded to a non-deploying effect. Because the member effects are read from the latest version, a member which isDeployIfNotExistsin the pinned version butAuditIfNotExistsin the latest version would have its role removed while the running assignment still requires it.With this defect fixed, the filter becomes safe by construction and defaulting it to
truecan be reconsidered.Related
Same family of problem as Azure/alzlib#248 and Azure/Azure-Landing-Zones#4190.
Suggested fix
Resolve the Policy Set definition at the assignment's pinned
definitionVersionwhen buildingpolicyRoleIdsand the policy set details used for the role calculation, falling back to the latest version only when no version is pinned.