anwather
commented
5 months ago It must be a 409 error if that message is triggering, parsing the result as you said will allow us to customise the message.
+1 for comments about monkeys interpreting colours 😅😅
I think we would keep this as a warning, only because removing the lock may require changes/other teams/approvals - in the meantime role deployment would be blocked which may lead to bigger issues.
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Benjamin Pieplow-Rohner @.> Sent: Monday, June 10, 2024 7:29:57 PM To: Azure/enterprise-azure-policy-as-code @.> Cc: Subscribed @.***> Subject: [Azure/enterprise-azure-policy-as-code] Role Assignments that fail due to a read-only resource lock do not throw an error (Issue #661)
Hi EPAC Team!
Describe the bug EPAC will create Service Principals for assignments, and assign the minimum required permissions (role assignments) automatically. However, if the resource getting this role assignment is protected by a resource lock (and possibly other safeguards - I have not tested this extensively) the role assignment fails, but the script fails silently. This leads to a discrepancy between the deployed state and the defined state, where the missing role assignment will impact policy automations.
To Reproduce Steps to reproduce the behavior:
- Create a resource (for example, a Log Analytics Workspace) and apply a read-only resource lock
- Create a policy assignment that requires a certain role on the resource (for example, Automation Contributor)
- Run a deployment pipeline including the "Roles" deployment stage
Expected behavior The role assignment will fail (as writing role assignments is prevented by the read-only resource lock). This should cause the script to return an error, encouraging the monkey behind the keyboard to investigate the strange red colors. Instead, the script returns, "Role assignment already exists (ignore): $($RoleAssignment.assignmentDisplayName)".
Screenshots/Info I can do one better than screenshots, the issue is a result of the error handling on line 37, script Set-AzRoleAssignmentRestMethod.ps1,
$statusCode = $response.StatusCode
if ($statusCode -lt 200 -or $statusCode -ge 300) {
if ($statusCode -eq 409) {
Write-Warning "Role assignment already exists (ignore): $($RoleAssignment.assignmentDisplayName)"
}
else {
$content = $response.Content
Write-Warning "Error, continue deployment: $($statusCode) -- $($content)"
}
}ARM will return the error,
"The scope '/subscriptions/SUBSCRIPTION_UUID/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.OperationalInsights/workspaces/WORKSPACE_NAME/providers/Microsoft.Authorization/roleAssignments/26e18bc7-c730-424b-9a17-019bbf7a66a1' cannot perform write operation because following scope(s) are locked: '/subscriptions/SUBSCRIPTION_UUID/resourceGroups/RESOURCE_GROUP_NAME'. Please remove the lock and try again."
Parsing this return for the term "remove the lock" will allow the script to explicitly handle this error.
EPAC Version 10.2.11
Thank you for your hard work on this project, I truly appreciate all your effort. --Benjamin
— Reply to this email directly, view it on GitHubhttps://github.com/Azure/enterprise-azure-policy-as-code/issues/661 or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACWCJVUDAM7DY73A56VS7WTZGVWZLBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJLJONZXKZNENZQW2ZNLORUHEZLBMRPXI6LQMWBKK5TBNR2WLKRSG4ZDKOJYHE2DOOFENZQW2ZNJNBQXGX3MMFRGK3ECUV3GC3DVMWSHI4TVMWSG4YLNMWXHOYLUMNUF6YLDORUXM2LUPGWHG5LCNJSWG5C7OR4XAZNFJFZXG5LFUZ2G64DJMNZZHAVEOR4XAZNKOJSXA33TNF2G64TZUV3GC3DVMWUTGMZXGE3DEOBTHCBKI5DZOBS2K2LTON2WLJLWMFWHKZNKGIZTIMZTHE3TMNJZQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRSG4ZDKOJYHE2DOOFHORZGSZ3HMVZKMY3SMVQXIZI. You are receiving this email because you are subscribed to this thread.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Hi EPAC Team!
Describe the bug EPAC will create Service Principals for assignments, and assign the minimum required permissions (role assignments) automatically. However, if the resource getting this role assignment is protected by a resource lock (and possibly other safeguards - I have not tested this extensively) the role assignment fails, but the script fails silently. This leads to a discrepancy between the deployed state and the defined state, where the missing role assignment will impact policy automations.
To Reproduce Steps to reproduce the behavior:
Expected behavior The role assignment will fail (as writing role assignments is prevented by the read-only resource lock). This should cause the script to return an error, encouraging the monkey behind the keyboard to investigate the strange red colors. Instead, the script returns,
"Role assignment already exists (ignore): $($RoleAssignment.assignmentDisplayName)".Screenshots/Info I can do one better than screenshots, the issue is a result of the error handling on line 37, script
Set-AzRoleAssignmentRestMethod.ps1,ARM will return the error,
Parsing this return for the term "remove the lock" will allow the script to explicitly handle this error.
EPAC Version 10.2.11
Thank you for your hard work on this project, I truly appreciate all your effort. --Benjamin