Terraform destroy authorization fails on Deploy VM Agents

[vidyambala]

Description

Resource group NetworkwatcherRG is not getting deleted by Terraform Destroy which resulted in Policy conflict when reapplying the Terraform

Steps to Reproduce

Terraform Apply
Terraform destroy
Steps to reproduce the behavior:
1.
2.

Expected behavior

Actual behavior

Screenshots

Additional context

Operating System:
Terraform Version:
Cloud (public, Azure Government, etc.):

[glennmusa]

Can you share a log of what which resulted in Policy conflict when reapplying the Terraform is being returned?

[shawngib]

This is as expected since Terraform or Bicep doesn't deploy this resource group, it is created when enabling Network Watcher which is global (regional). We can modify the this to use one we create but that is not normal.

[vidyambala]

Can you share a log of what which resulted in Policy conflict when reapplying the Terraform is being returned?

Part of the log is from bicep deployment after TF destroy in same subscription.... i am not sure this is related to NetworkWatcher. Sunscription and client IDs are redacted.

Deployment failed with multiple errors: 'Authorization failed for template resource 'Deploy VMSS Agents cicdbicep-hub' of type 'Microsoft.Authorization/policyAssignments'. The client 'xxxxxx' with object id 'xxxxxx' does not have permission to perform action 'Microsoft.Authorization/policyAssignments/write' at scope '/subscriptions/xxxxxxxxx/resourceGroups/cicdbicep-hub/providers/Microsoft.Authorization/policyAssignments/Deploy VMSS Agents cicdbicep-hub'.:Authorization failed for template resource 'Deploy VM Agents cicdbicep-hub' of type 'Microsoft.Authorization/policyAssignments'.

[shawngib]

Have you recreated service principles? This appears to be related to the user(SP) doing the deployment not having correct permissions to write to policyAssignments.

[shawngib]

Example of was done in the earlier script version of MLZ when we created SP's on the fly. 'Resource Policy Contributor' is required and not default as part of contributor.

az role assignment create \
                --role 'Resource Policy Contributor' \
                --assignee-object-id "${sp_object_id}" \
                --scope "/subscriptions/${sub}" \
                --assignee-principal-type ServicePrincipal \
                --output none

[vidyambala]

Have you recreated service principles? This appears to be related to the user(SP) doing the deployment not having correct permissions to write to policyAssignments.

yes and and the same is working for TF and gov cloud. it was working last week i merged my branch with upstream branch main

[glennmusa]

Does running the role assignment create command @shawngib described on the object ID and subscription scope described in your error (The client 'xxxxxx' with object id 'xxxxxx' does not have permission to perform action 'Microsoft.Authorization/policyAssignments/write' at scope '/subscriptions/...) resolve the error?

[vidyambala]

Does running the role assignment create command @shawngib described on the object ID and subscription scope described in your error (The client 'xxxxxx' with object id 'xxxxxx' does not have permission to perform action 'Microsoft.Authorization/policyAssignments/write' at scope '/subscriptions/...) resolve the error?

nope...:( checking on couple of things

[glennmusa]

Initial assumption seems to be a resource not exists error that stems from naming collisions with not-existing but not-yet-deprovisioned resources: #498

Gonna close for now @vidyambala -- but happy to re-open or reference in another Issue if @shawngib is able to track down a root cause.