Improvement for Policy: Audit diagnostic setting

[SenthuranSivananthan]

This policy doesn't allow for customizing the type of diagnostic information to send to a sink like Log Analytics Workspace. It assumes that metrics & logs will always be forwarded. Unfortunately, my customers don't push metrics to LAW due to ingestion latency and cost implications. We leverage Azure Monitor Metrics for all metrics.

Recommendation

Add two parameters: LogsEnabled and MetricsEnabled so that we can set the correct type of data to be forwarded during assignment. Assignment can be either of the policy or the initiative that uses this policy.

This policy is used by initiatives such as Canada Federal PBMM and HITRUST/HIPAA.

Current Policy Definition

{
  "properties": {
    "displayName": "Audit diagnostic setting",
    "policyType": "BuiltIn",
    "mode": "All",
    "description": "Audit diagnostic setting for selected resource types",
    "metadata": {
      "version": "1.0.0",
      "category": "Monitoring"
    },
    "parameters": {
      "listOfResourceTypes": {
        "type": "Array",
        "metadata": {
          "displayName": "Resource Types",
          "strongType": "resourceTypes"
        }
      }
    },
    "policyRule": {
      "if": {
        "field": "type",
        "in": "[parameters('listOfResourceTypes')]"
      },
      "then": {
        "effect": "AuditIfNotExists",
        "details": {
          "type": "Microsoft.Insights/diagnosticSettings",
          "existenceCondition": {
            "allOf": [
              {
                "field": "Microsoft.Insights/diagnosticSettings/logs.enabled",
                "equals": "true"
              },
              {
                "field": "Microsoft.Insights/diagnosticSettings/metrics.enabled",
                "equals": "true"
              }
            ]
          }
        }
      }
    }
  },
  "id": "/providers/Microsoft.Authorization/policyDefinitions/7f89b1eb-583c-429a-8828-af049802c1d9",
  "type": "Microsoft.Authorization/policyDefinitions",
  "name": "7f89b1eb-583c-429a-8828-af049802c1d9"
}

[JimGBritt]

@SenthuranSivananthan can you be more specific? This is already enabled in the script and can be utilized today to turn metrics off (it is by default) while turning logs on, vice versa. This is also useful for enabling and disabling the configuration on demand across the environment (by also leveraging the remediation script I have for Policy Initiatives in this repo). See below the snip from an exported policy generated from the script that provides both metrics and logs to be independently toggled.

     "metricsEnabled": {
        "type": "String",
        "metadata": {
          "displayName": "Enable Metrics",
          "description": "Enable Metrics - True or False"
        },
        "allowedValues": [
          "True",
          "False"
        ],
        "defaultValue": "False"
      },
      "logsEnabled": {
        "type": "String",
        "metadata": {
          "displayName": "Enable Logs",
          "description": "Enable Logs - True or False"
        },
        "allowedValues": [
          "True",
          "False"
        ],
        "defaultValue": "True"
      }

Related to the subject of the issue on Audit, I plan on looking at implementing auditIfNotExists as a parameter along with deployIfNotExists and Disable (essentially making them parameters for effect) but not until I get the latest PR merged and released.

[SenthuranSivananthan]

Thanks for the chat yesterday @JimGBritt. I think I opened this issue in the wrong repo given it's a built-in policy.

I've copied the details to Azure/azure-policy#870 so that Azure Policy engineering team can evaluate the change. Given this will have a cascading impact to initiatives as well.