-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Comments
@NVolcz I've followed your PR comment and this issue, while in the cmdlet you provided above, you'll set Meanwhile, I've submit another PR #11502 to support the automation rule, which shall supersedes the alert rule action. |
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 |
@NVolcz Thank you for pointing the diff! It makes sense to implement 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 |
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? |
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. |
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. 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 |
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.
|
@NVolcz 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. |
Will take a look at #1691 and see if there is anything I can help with there. |
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 |
@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? |
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. |
Community Note
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 alogic_app_trigger_name
property. Thelogic_app_trigger_name
is used to fetch thetriggerUri
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 thetriggerUri
when reading action rules which is required since theazurerm_sentinel_alert_rule_action
resource requireslogic_app_trigger_name
which abstractstriggerUri
.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 thelogic_app_trigger_name
property entirely and fetch thetriggerUri
with thelogic_app_id
.Here is an example for how to create an action with PowerShell (It helped me understand the API):
New or Affected Resource(s)
Potential Terraform Configuration
A new suggestion for unblocking the pull request:
References
The text was updated successfully, but these errors were encountered: