feat: Insights/scheduledQueryRule - Added missing properties

[AlexanderSehr]

Description

• Added missing actions properties
• Added test case for actions
• Updated to use avm-common-types

Closes #4708

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[ahmadabdalla]

I would like to suggest adding support for managed identity as well. I've implemented this for a customer recently:

var formattedUserAssignedIdentities = reduce(
  map((managedIdentities.?userAssignedResourceIds ?? []), (id) => { '${id}': {} }),
  {},
  (cur, next) => union(cur, next)
) //

var identity = !empty(managedIdentities)
  ? {
      type: (managedIdentities.?systemAssigned ?? false)
        ? (!empty(managedIdentities.?userAssignedResourceIds ?? {}) ? 'UserAssigned' : 'SystemAssigned')
        : (!empty(managedIdentities.?userAssignedResourceIds ?? {}) ? 'UserAssigned' : 'None')
      userAssignedIdentities: !empty(formattedUserAssignedIdentities) ? formattedUserAssignedIdentities : null
    }
  : null

Reference: https://learn.microsoft.com/en-us/azure/templates/microsoft.insights/scheduledqueryrules?pivots=deployment-language-bicep

Additional properties locks, roleAssignments

[ahmadabdalla]

Note: Managed identity with Log Search Rule

[AlexanderSehr]

Hey @ahmadabdalla,
sounds good, will do :) I am however struggling adding a test case for the original changes of this PR (referencing an action group with parameters) which is currently blocking me a bit in finishing it (ref) 😄
In other words - it may take a moment to merge the change as I feel like I'm searching for a solution in the dark.

[AlexanderSehr]

Alright, added & tested. 💪 I used the fail() function to ensure a user knows they can only either define a system-assigned or user-assigned identity. Seemed appropriate at the time. 😏

If you configure both, the deployment would fail with the error message: 14:56:19 - The deployment 'a-r-i-sqr-max-t1-20250318T1403155517Z' failed with error(s). Showing 1 out of 1 error(s). Status Message: Deployment template validation failed: 'The template variable 'identity' is not valid: You can only configure either a system-assigned or user-assigned identities, not both.. Please see https://aka.ms/arm-functions for usage details.'. (Code:InvalidTemplate)

Learned about this fancy feature in a post by @sebassem today 🚀

[ahmadabdalla]

Sorry I missed these messages! I am glad it's working! Thank you @AlexanderSehr

[ahmadabdalla]

hmmm I do remember seeing something like this. Can you try deploying a new test LAW just for testing sake.

[AlexanderSehr]

Hey @ahmadabdalla, thanks for the suggestion. Just tested it (so far without luck). The web has also not yet yielded any insights. But I'll continue testing options

[ahmadabdalla]

Hey @AlexanderSehr couple of things I did from a testing perspective before:

• Set the max test case to use system identity.
• Created a separate test case for Azure Resource Graph queries with user identities using the following properties for main.test.bicep:

module nestedDependencies 'dependencies.bicep' = {
  scope: resourceGroup
  name: '${uniqueString(deployment().name, resourceLocation)}-nestedDependencies'
  params: {
    managedIdentityName: 'dep-${namePrefix}-msi-${serviceShort}'
    location: resourceLocation
  }
}

resource managedIdentityRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid('Custom seed ${namePrefix}${serviceShort}')
  properties: {
    roleDefinitionId: subscriptionResourceId(
      'Microsoft.Authorization/roleDefinitions',
      'acdd72a7-3385-48ef-bd42-f606fba81ae7' // 'Reader' role
    )
    principalId: nestedDependencies.outputs.managedIdentityPrincipalId
    principalType: 'ServicePrincipal'
  }
}

// ============== //
// Test Execution //
// ============== //

@batchSize(1)
module testDeployment '../../../main.bicep' = [
  for iteration in ['init', 'idem']: {
    scope: resourceGroup
    name: '${uniqueString(deployment().name, resourceLocation)}-test-${serviceShort}-${iteration}'
    params: {
      name: '${namePrefix}${serviceShort}001'
      location: resourceLocation
      managedIdentities: {
        userAssignedResourceIds: [
          nestedDependencies.outputs.managedIdentityResourceId
        ]
      }
      alertDescription: 'My sample Alert'
      autoMitigate: false
      criterias: {
        allOf: [
          {
            query: 'arg("").PolicyResources\n| where type =~ \'Microsoft.PolicyInsights/PolicyStates\'\n'
            timeAggregation: 'Count'
            dimensions: []
            operator: 'GreaterThan'
            threshold: json('10')
            failingPeriods: {
              numberOfEvaluationPeriods: 1
              minFailingPeriodsToAlert: 1
            }
          }
        ]
      }
      evaluationFrequency: 'PT5M'
      queryTimeRange: 'PT5M'
      alertDisplayName: '${uniqueString(deployment().name, resourceLocation)}-displayNameTest-${serviceShort}-${iteration}'
      scopes: [
        subscription().id
      ]
      suppressForMinutes: 'PT5M'
      windowSize: 'PT5M'
    }
    dependsOn: [
      managedIdentityRoleAssignment
    ]
  }
]

I noticed from your test case you aren't granting permissions for the user identity to the workspace.

Based on the doco:

"If the query is accessing a Log Analytics workspace, the identity must be assigned a reader role for all workspaces that the query accesses. If you're creating resource-centric log search alerts, the alert rule might access multiple workspaces, and the identity must have a reader role on all of them."

[AlexanderSehr]

I'll be damned, you're of course right @ahmadabdalla. After you created this nice little trap with the added support for MSIs you also solved it for me 😄.
Had a hunch that it might be because of the LAW permissions, but it failed so fast that it seemed even more fundamental.

[ahmadabdalla]

Most importantly.. did it work :D