Write Azure policy to deny adding a second diagnostic setting to any resource if the first diagnostic setting already exists

jarvis-8094 0

I tried the below code, but it doesn't seem to have any resource details and it doesn't work

{ "mode": "All", "policyRule": { "if": { "field": "type", "equals": "Microsoft.Insights/diagnosticSettings" }, "then": { "effect": "deny" } }, "parameters": {} }

AnuragSingh-MSFT 21,386 Reputation points

2023-11-08T07:21:50.9666667+00:00
jarvis8094, thank you for posting this question on Microsoft Q&A.

I tested a couple of scenarios, but it does not seem possible because Azure Policy works based on target. You may get an idea of how this works by looking at build-in policy definitions available in initiative "Enable audit category group resource logging for supported resources to Log Analytics"

This initiative contains a number of policies and each one targets a specific resource. There is no master policy which can get this task done for all resources.

I tested the policy definition shared in the question, and it works to deny diagnostic setting creation for all resources. After creating and assigning a policy a few minutes are required for it to become effective. Hence you may not see its impact immediately but after a while. In my case, it worked and denied creation of diagnostic settings, irrespective of whether the resource already had it or not.

Workarounds

There are 2 workarounds that I could think of to achieve this scenario

RBAC - The contributor role is the only built-in role which has the ability to create diagnostic settings. You could use this feature to provide the ability to create diagnostic settings only to selected set of users who are aware of the org policy to not create second diagnostic settings.

Audit policy - Another option that could be explored is to use "Audit" effect in Azure policy to check for resources which have more than 1 diagnostic setting. This should be doable (I have not tested it though) because the approach here would be check for field and not to figure out the containing resource from target (as is the case in policy definition shared in question). While this approach will not deny the creation of diagnostic setting, it will flag resources which have more than 1 diagnostic setting enabled.

Hope this helps.

If the reply did not help, please add more context/follow-up question for it, and we will help you out.

jarvis-8094 0

@AnuragSingh-MSFT I don't think we could do the audit policy since we can't use Microsoft.Insights/diagnosticSettings[*] in the count field.

Am I missing something here?

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Insights/diagnosticSettings"
        },
        {
          "count": {
            "field": "Microsoft.Insights/diagnosticSettings[*]",
            "where": {
              "allOf": [
                {
                  "field": "Microsoft.Insights/diagnosticSettings/workspaceId",
                  "exists": "true"
                }
              ]
            }
          },
          "greater": 1
        }
      ]
    },
    "then": {
      "effect": "audit"
    }
  },
  "parameters": {}
}

AnuragSingh-MSFT 21,386 Reputation points

2023-11-15T08:19:43.84+00:00

jarvis-8094, thank you for the reply.

You are right, I also could not use the count for diagnostic settings as it is not really part of the resource itself, it seems. I have reached out internally as well to see if there is a way to make this work.

1 answer

AnuragSingh-MSFT 21,386 Reputation points

2023-12-19T05:47:58.9766667+00:00

jarvis-8094, Apologies for the delayed response.

Today, it is not possible through Azure Policy for a policy to take effect based on the existence of other resources. We do have deployIfNotExists policies which can automate the process of deploying diagnostic settings if they do not yet exist for a resource, but these do not prevent manual deployment of another diagnostic setting on the same resource.

You would need to use another method to check for existence of such diagnostic settings before deployment. This could be done using an automation runbook or a logic app, which could call the diagnosticSettings API for this information.

Hope this helps.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Write Azure policy to deny adding a second diagnostic setting to any resource if the first diagnostic setting already exists

1 answer

Your answer