Azure / azure-policy

Repository for Azure Resource Policy built-in definitions and samples
MIT License
1.49k stars 1.08k forks source link

Require a tag on resource groups: modify policyRule to exclude resourcegroup name auto-created from azure portal to avoid errors on deployment #1265

Open paoIpao opened 7 months ago

paoIpao commented 7 months ago

ISSUE DESCRIPTION: policy rule: "azure-policy/built-in-policies/policyDefinitions/Tags/ResourceGroupRequireTag_Deny.json" the policeRule not exclude some standard/default resourcegroup so built-in policy it is useless and generate deployment errros very annoing..

Details of the scenario you tried and the problem that is occurring

implemented policy require a tag on resource groups. when create default azure cloud shell go to error because default RG not have the tag.. when create first backup and execute it go to critical error because AzureBackupRG* not have the tag..

Suggested solution to the issue

{ "properties": { "displayName": "Require a tag on resource groups", "policyType": "BuiltIn", "mode": "All", "description": "Enforces existence of a tag on resource groups.", "metadata": { "version": "1.0.0", "category": "Tags" }, "parameters": { "tagName": { "type": "String", "metadata": { "displayName": "Tag Name", "description": "Name of the tag, such as 'environment'" } } }, "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Resources/subscriptions/resourceGroups" }, { "field": "name", "notLike": "AzureBackupRG*" }, { "field": "name", "notLike": "ResourceMover*" }, { "field": "name", "notLike": "rg-cloudshell" }, { "field": "name", "notLike": "cloud-shell-storage-*" }, { "field": "name", "notLike": "databricks-rg*" }, { "field": "name", "notLike": "NetworkWatcherRG" }, { "field": "name", "notLike": "microsoft-network" }, { "field": "name", "notLike": "LogAnalyticsDefaultResources" }, { "field": "name", "notLike": "DynamicsDeployments*" }, { "field": "[concat('tags[', parameters('tagName'), ']')]", "exists": "false" } ] }, "then": { "effect": "deny" } } }, "id": "/providers/Microsoft.Authorization/policyDefinitions/96670d01-0a4d-4649-9c89-2d3abc0a5025", "type": "Microsoft.Authorization/policyDefinitions", "name": "96670d01-0a4d-4649-9c89-2d3abc0a5025" }

andaryjo commented 7 months ago

You should deploy a policy with a custom policy definition then. Seemingly the built-in policy works as advertised, even though it breaks some Azure built-in functionality. Resources should not be exempt from a policy just because they get created by an Azure resource provider.

Additionally, if you want to ensure a certain configuration on a resource, try to use audit / modify effect policies over deny effect policies. This way you don't break deployment flows for some Azure clients. I have observed many instances where a deny effect policy would break the Azure Portal creation wizards because they simply do not support the configuration the policy is enforcing. See for example: https://gist.github.com/andaryjo/f019d889148dbebba38e8adcd2e95aa7#what-do-we-do-now

paoIpao commented 7 months ago

Yes, we want that the policy "when owner create RG MUST specify same tag", but not want the azure backup go to critical error when first backup job it executed and not working by default because the RG create by "system services azure backup" (or others) go to error like "AzureBackupRG*". built-in policy "require" are useless if broken azure, maybe an option parameter (array?) to exclude some RG name with a certain pattern (notLike operator) can be the right choice.