Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for azurerm_sentinel_alert_rule_action #11366

Closed
NVolcz opened this issue Apr 19, 2021 · 13 comments
Closed

Support for azurerm_sentinel_alert_rule_action #11366

NVolcz opened this issue Apr 19, 2021 · 13 comments

Comments

@NVolcz
Copy link
Contributor

NVolcz commented Apr 19, 2021

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

Description

It looks to be possible to unblock #6820 without the having Microsoft changing their API.
To my understanding, #6820 is blocked because the Pull Request's azurerm_sentinel_alert_rule_action requires a logic_app_trigger_name property. The logic_app_trigger_name is used to fetch the triggerUri which is required by the Azure REST API when creating or updating an action rule but not returned by the API when reading. The blocking issue from this perspective is that the Azure API does not return the triggerUri when reading action rules which is required since the azurerm_sentinel_alert_rule_action resource requires logic_app_trigger_name which abstracts triggerUri.

I have tried to ask Microsoft about this issue and to my understanding, triggerUri is only used when creating the action rule then internally discarded, hence not possible to return it. We can therefor discard the logic_app_trigger_name property entirely and fetch the triggerUri with the logic_app_id.

Here is an example for how to create an action with PowerShell (It helped me understand the API):

$SentinelConnection = @{
    ResourceGroupName = "yourResourceGroupName"
    WorkspaceName = "yourWorkspaceName"
}

$LogicAppConnection = @{
    ResourceGroupName = "yourLogicAppsResourceGroupName"
    Name = "yourLogicAppName"
}

$LogicAppResourceId = Get-AzLogicApp @LogicAppConnection
$LogicAppTriggerUri = Get-AzLogicAppTriggerCallbackUrl @LogicAppConnection -TriggerName "When_a_response_to_an_Azure_Sentinel_alert_is_triggered"
$AnalyticsRule = Get-AzSentinelAlertRule @SentinelConnection | Where-Object {$PSItem.DisplayName -eq "yourRuleName"}
$AlertRuleAction = New-AzSentinelAlertRuleAction @SentinelConnection `
-AlertRuleId $AnalyticsRule.Name `
-LogicAppResourceId ($LogicAppResourceId.Id) `
-TriggerUri ($LogicAppTriggerUri.Value)  

New or Affected Resource(s)

  • azurerm_sentinel_alert_rule_action

Potential Terraform Configuration

A new suggestion for unblocking the pull request:

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_log_analytics_workspace" "example" {
  name                = "example-workspace"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku                 = "pergb2018"
}

resource "azurerm_sentinel_alert_rule_scheduled" "example" {
  name                       = "example-alert-rule"
  log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id
  display_name               = "example"
  severity                   = "High"
  query                      = <<QUERY
AzureActivity |
  where OperationName == "Create or Update Virtual Machine" or OperationName =="Create Deployment" |
  where ActivityStatus == "Succeeded" |
  make-series dcount(ResourceId) default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller
QUERY
}

resource "azurerm_logic_app_workflow" "example" {
  name                = "example-workflow"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}

resource "azurerm_logic_app_trigger_custom" "example" {
  name         = "When_a_response_to_an_Azure_Sentinel_alert_is_triggered"
  logic_app_id = azurerm_logic_app_workflow.example.id
  body = <<BODY
{
    "type": "ApiConnectionWebhook",
    "inputs": {
        "body": {
            "callback_url": "@{listCallbackUrl()}"
        },
        "host": {
            "connection": {
                "name": "@parameters('$connections')['azuresentinel']['connectionId']"
            }
        },
        "path": "/subscribe"
    }
}
BODY
}

resource "azurerm_sentinel_alert_rule_action" "example" {
  name                   = "example-alert-rule-action"
  sentinel_alert_rule_id = azurerm_sentinel_alert_rule_scheduled.example.id
  logic_app_id           = azurerm_logic_app_trigger_custom.example.logic_app_id
}

References

@magodo
Copy link
Collaborator

magodo commented Apr 28, 2021

@NVolcz I've followed your PR comment and this issue, while in the cmdlet you provided above, you'll set -TriggerUri ($LogicAppTriggerUri.Value) when creating the alert rule action, isn't this the same as we pass in the logic_app_trigger_name?

Meanwhile, I've submit another PR #11502 to support the automation rule, which shall supersedes the alert rule action.

@NVolcz
Copy link
Contributor Author

NVolcz commented Apr 29, 2021

Great to hear about the PR for the automation rules! It will be super useful! There is however a difference in functionality between automation rules and playbooks being triggered by the alert rules. Automation are triggered when an incident has been created and alert rules triggers playbooks when an alert has been created.

It looks to me that logic_app_trigger_name would be the equivalent of When_a_response_to_an_Azure_Sentinel_alert_is_triggered in the my powershell script above and ($LogicAppTriggerUri.Value) would be something like https://prod-17.westeurope.logic.azure.com:443/workflows/SOMEID?api-version=2016-06-01&SOMESECRETS

@magodo
Copy link
Collaborator

magodo commented Apr 30, 2021

@NVolcz Thank you for pointing the diff! It makes sense to implement azurerm_sentinel_alert_rule_action along with the automation rule.

The name you used is the default name that is created on Portal (the workflow desiner). Whilst the name can be something else, if it is created via other means (e.g. via azurerm_logic_app_trigger_custom). Therefore, we still need the users to provide the name, tbn.

@NVolcz
Copy link
Contributor Author

NVolcz commented Apr 30, 2021

I am not sure if it is possible to change the name. I believe there only can be a single trigger of the same type, couldn't we simply enumerate the logic app's triggers and select the trigger of the correct type?

@NVolcz
Copy link
Contributor Author

NVolcz commented Apr 30, 2021

I double checked my suggestion in the previous comment and it seems to not be possible to do it the way I initially thought. There seems to be no obvious way to find the type of the logic app trigger.
The Sentinel blade in the Azure portal seems to be filtering logic apps some logic apps. I can't create an action rule for logic app s that only have recurrence triggers. Also, if I create an action rule for a logic app with multiple trigger, the Azure portal selects the last one.

@kaovd
Copy link
Contributor

kaovd commented May 1, 2021

Great to hear about the PR for the automation rules! It will be super useful! There is however a difference in functionality between automation rules and playbooks being triggered by the alert rules. Automation are triggered when an incident has been created and alert rules triggers playbooks when an alert has been created.

pretty sure this is superseded now by Automation Rules, incidents are created for everything regardless. Classic playbook alert triggers would trigger on the sentinel alert when it fired. That alert then creates an incident in sentinel. Effectively, whatever it is, it ends up in an incident and can be used in automation rules.
When you are in the logic app using the preview incident trigger, If the alert is a Azure Sentinel KQL alert, you additionally get some properties that you would of had in the old standard alert trigger (as it is possible for an incident to contain multiple alerts depending on your config).

With the way its going logic app alert triggers are soon to be legacy from the looks of it with Ms's pretty much straight up refusal to fix their API. While this is nice to have I don't see urgency needing this anymore as automation rules do handle both. Although if else would be good to hear your thoughts

@NVolcz
Copy link
Contributor Author

NVolcz commented Sep 10, 2021

I am not sure that alert rules will be superseded by Automation rules. It is for example possible to create security alerts without incidents, it is possible to trigger a logic app workflow on this.

  • Trigger on Alert -> Alert Rule
  • Trigger on Incident -> Automation Rule

@kaovd
Copy link
Contributor

kaovd commented Sep 16, 2021

@NVolcz
Alerts should pretty much always result in Incidents and while having them both is great have a feeling down the line MS will probably switch.

Anyways none of this is getting pulled in the first place as we are still eternally blocked on the Logic App connections not working properly, Provider maintainers require tests do not use arm templates which was the only way to preform tests for Logic App triggers in the automation PR.
#1691

@NVolcz
Copy link
Contributor Author

NVolcz commented Sep 20, 2021

Will take a look at #1691 and see if there is anything I can help with there.
@kaovd, Unless you have a credible source for future Microsoft plans, I would be careful making assumptions about the alert action. Many customers are actively using this today, so I have a hard time imagining this going away anytime soon.

@kaovd
Copy link
Contributor

kaovd commented Sep 20, 2021

Will take a look at #1691 and see if there is anything I can help with there.
@kaovd, Unless you have a credible source for future Microsoft plans, I would be careful making assumptions about the alert action. Many customers are actively using this today, so I have a hard time imagining this going away anytime soon.

Im not saying that we shouldnt have both just in my experience incident Automation rules make alert triggers redundant although thats not really the issue here

Ive considered the effort costs of forking some of this functionality as it seems silly these vital components of functionality for us are blocked due to having an arm template in a test although for now I don't suppose script provisioning the patch for that property is too bad

From what I hear at MS, while there is a lot of us asking about this stuff currently we are more small individual voices. Would certainly be nice if there was a interest group around as obviously if there was a centralized voice might make MS focus more on getting SecurityInsights packages out faster as dosent seem it gets much love as other RPs atm

@magodo
Copy link
Collaborator

magodo commented Nov 2, 2021

@NVolcz I've got credit from the sentinel service team that they're already aware of the issue as stated in the Azure/azure-rest-api-specs#9424. While they have no plan to fix that. On the other hand, they are planning to deprecate the alert rule action in favor of the automation rule, as the latter is a superset of the alert rule action.

As said above, currently there is nothing we can do to move this issue forward. Also, we already have the alternative solution for your use case (though need to include some arm template for other reason). Do you mind we close this issue for now?

@magodo
Copy link
Collaborator

magodo commented Nov 19, 2021

@NVolcz I'm gonna close this issue as explained above. Please feel free reopen it if you have any any use case that can't be covered by the azurerm_automation_rule.

@magodo magodo closed this as completed Nov 19, 2021
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants