Azure Policy Assignments - ascExportResourceGroupName

[gerrynicol]

Describe the feature end to end, including deployment scenario details under which the feature would occur.

The ALZ policy assignment module has multiple parameters that can be configured in alzDefaultPolicyAssignments.parameters.all.json. Could the parameter "ascExportResourceGroupLocation" in policy_assignment_es_deploy_mdfc_config.tmpl.json be added as a newly configurable parameter and also allow for Tagging of this resource group.

Why is this feature important. Describe why this would be important for your organization and others. Would this impact similar orgs in the same way?

Some customers want to change the name of this resource group, which is fairly straightforward. The issue is when there is tagging enforced on the Resource group also. The assignment then fails to deploy to the newly named resource group because of a deny rule for tagging (Even though the resource group has been pre-created with the required tags).

Please provide the correlation id associated with your error or bug.

"submissionTimestamp": "2024-08-29T10:59:44Z",,
"properties": {
    "isComplianceCheck": "False",
    "resourceLocation": "",
    "ancestors": ",",
    "policies": "[{\"policyDefinitionId\":\"/providers/Microsoft.Authorization/policyDefinitions/96670d01-0a4d-4649-9c89-2d3abc0a5025\",\"policyDefinitionName\":\"96670d01-0a4d-4649-9c89-2d3abc0a5025\",\"policyDefinitionDisplayName\":\"Require a tag on resource groups\",\"policyDefinitionEffect\":\"deny\",\"policyAssignmentId\"

Can you describe any alternatives that you have taken since this feature does not exist?

No response

Feature Implementation

No response

Check previous GitHub issues

• [X] I have searched the issues for this item and found no duplicate

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[jtracey93]

Hey @gerrynicol,

Thanks for the ask here. Have transferred to the upstream ALZ policy repo as this isn't specific to ALZ Bicep.

Also looping in @Springstone for his views.

This would require a change to the built in policy of https://www.azadvertizer.net/azpolicyadvertizer/ffb6f416-7bd2-4488-8828-56585fef2be9.html that we wrap into the initiative of https://www.azadvertizer.net/azpolicyinitiativesadvertizer/Deploy-MDFC-Config.html.

This would need to be done by the MDFC PG. Could you raise a support ticket for this and let us know the ID so we can then use this to speak with the MDFC PG with some actual customer evidence? 👍

[gerrynicol]

Thanks for the guidance @jtracey93. I have raised a support ticket

Support request ID 2408290050004117

[jtracey93]

@Springstone when you get 5, love your insights and thoughts here on how we can maybe get it to the PG faster?

[Springstone]

@gerrynicol this is a minor issue and we'll get a fix in asap. To clarify, the policy in question already caters for what you need, with the exception of creating a resource group with tags (which is near impossible to implement in policy). The process, if you have tag enforcement in place, is to pre-create the resource group with all the tags you need, and to specify that resource group and location in the assignment. The 3 parameters we expose in the initiative are: resourceGroupName, resourceGroupLocation and workspaceResourceId. However, we're missing the createResourceGroup Boolean parameter that defaults to true (we need to set this to false for your scenario) from the property description:

If a resource group does not exists in the scope, a new resource group will be created. If the resource group exists and this flag is set to 'true' the policy will re-deploy the resource group. Please note this will reset any Azure Tag on the resource group.

The last sentence above explains why this is failing for your scenario.

We'll expose that parameter in the initiative and assignment but keep the default "true" for the portal accelerator experience (which is intended for greenfield deployments). As you're deploying through Terraform, you'll be able to update that parameter in the assignment prior to deployment.

I hope this addresses your concern, feel free to drop your feedback here.

[gerrynicol]

@Springstone That sounds perfect. Thanks for the update.

[Springstone]

Tracking in AB#37722

[Springstone]

This is merged in #1789