policy_definition_es_deploy_diagnostics_*.json policies shouldn't have hardcoded existence condition

[adrianjagodzinski]

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: 1.3.4

azure provider: 3.60.0

module: 2.4.1

Description

You can deploy the diagnosticSettings with parameters like logsEnabled and metricsEnabled but the condition for assertion of whether the resource is compliant doesn't take into account these parameters, only hardcoded values. So it is possible to end up in a situation that you supply logs_enabled = "true" and metrics_enabled = "false" and end up with a non-compliant resource.

Steps to Reproduce

1. Take the following policy: https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/blob/main/modules/archetypes/lib/policy_definitions/policy_definition_es_deploy_diagnostics_bastion.json
2. Supply it with params: logsEnabled = "true" and metricsEnabled = "false"
3. Your policy will never be compliant.

Screenshots

[matt-FFFFFF]

Moving upstream

[Springstone]

Hi @adrianjagodzinski, thanks for raising this. We have several open issues around diagnostic settings and metrics/logs. The issue you have raised is valid, however, at the moment we are holding on making significant changes as the product groups are busy preparing a "v2" of diagnostic settings that will consist of built-in policies that allow more granular configuration. Once these are available, we will transition our default assignments to leverage those.

[Springstone]

Closing this as we've deprecated all our diagnostic settings policies and shifted to the PG owned initiative to do the same. Please review https://aka.ms/alz/whatsnew for details.