Enterprise-Scale
Enterprise-Scale copied to clipboard
Azure
Effect parameter missing in policy set definition for RecoveryVaultDeployDiagnosticLogDeployLogAnalytics
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Versions
terraform: v1.3.7
azure provider: azurerm
module: archetypes
Description
Describe the bug
The "effect" parameter appears to have been missed in the policyDefinitionReferenceId block for RecoveryVaultDeployDiagnosticLogDeployLogAnalytics in the policy set definition JSON code:
/modules/archetypes/lib/policy_set_definitions/policy_set_definition_es_deploy_diagnostics_loganalytics.tmpl.json
lines 1625-1636
Steps to Reproduce
Screenshots
Additional context
Hi @JoshuaMcConnaughey This is the same upstream so moving issue to Enterprise-Scale
Hi @JoshuaMcConnaughey it seems the effect parameter is not present in the built-in definition
https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc717fb0c-d118-4c43-ab3d-ece30ac81fb3
Hello @matt-FFFFFF - thank you for getting back to me!
The Enterprise-Scale initiative that deploys this policy has a parameter for "Effect" that is used by every policy in the initiative except the Recovery Vault policy I called out in my initial post. The initiative is a combination of Custom and Built-in policies. For consistent behavior of the "Effect" parameter across all the intiative's policies, I would recommend that this Recovery Vault policy be replaced with a custom version of the built-in policy with the "Effect" parameter incorporated.
The screenshot below illustrates how this policy alone does not receive the "Effect" parameter from the initiative:
Thanks Both, we really would prefer to avoid creating customs if we can avoid it and instead get the owners of the built-in definitions to fix/enhance their policy.
Looping in @paulgrimley can we get this tracked in ADO and then maybe one to raise to your contact in the backup/ASR PG as an ask?
AB#27602 assigned to @Springstone to pursue - note as this is built-in owned by BCDR team we are reliant on them for timescales to fix this so please do not expect a rapid turnaround on this as it is not a bug as such.
Minor update: the discrepancy has been acknowledged and is being investigated. As Paul mentioned it will likely take some time for this to be addressed.
@JoshuaMcConnaughey I've had confirmation that this will be looked at in this semester of work that the BCDR team have planned as they are the policy owners / authors which will be by end of September latest - these timelines are out of our hands unfortunately. cc: @Springstone