Adds new resource azurerm_security_center_automation for automation and data export

[benc-uk]

Adds new resource for configuring export of Security Center alerts and recommendations to a range of destinations
This is done via what is referred to in Security Center as "workflow automation" and "continuous export"

• https://docs.microsoft.com/en-gb/azure/security-center/continuous-export
• https://docs.microsoft.com/en-gb/azure/security-center/workflow-automation

Fixes #8611

Example resource to send alerts to a Logic App

resource "azurerm_security_center_automation" "example" {
  name                = "acctest-automation"
  location            = "uksouth"
  resource_group_name = "testing"

  scopes = [
    "/subscriptions/${data.azurerm_client_config.current.subscription_id}"
  ]

  action {
    type        = "LogicApp"
    resource_id = azurerm_logic_app_workflow.example.id
    trigger_url = "https://example.net/foo"
  }

  source {
    event_source = "Alerts"
    rule_set {
      rule {
        property_path = "properties.metadata.severity"
        operator = "Equals"
        expected_value = "Low"
        property_type = "String"
      }
  }
}

This resource supports three types of destination in the action, Logic App as shown above, but also Log Analytics and Event Hubs

action {
  type        = "LogAnalytics"
  resource_id = azurerm_log_analytics_workspace.example.id
}

action {
  type        = "EventHub"
  resource_id = azurerm_eventhub_namespace.example.id
  connection_string = azurerm_eventhub_namespace.example.default_primary_connection_string
}

Notes.

• The source, action blocks can be specified multiple times
• Argument action.type must be one of LogicApp, EventHub or LogAnalytics
• The action.connection_string argument is only required when type is EventHub, this must be a valid Event Hub connection string
• The action.trigger_url argument is only required when type is LogicApp, this must be a valid URL, and should be the callback POST URL shown in the Logic App portal trigger history
• The scopes argument is an list of resource or subscription ids (at least one)
• The rule_set and rule block of an action can also be configured multiple times, and an action can be created without any rule_set(s)
• Argument source.event_source must be one of Alerts, Assessments or SubAssessments

When setting up rules, the schema of the source data needs to be known in order to set the property_path & property_type fields. The schema for Security Center alerts can be found here. The schema for Assessments & SubAssessments seems undocumented, but can be reverse engineered by configuration via the portal and then inspection with the API
az rest --url "https://management.azure.com/subscriptions/_subid_/resourceGroups/_rg_/providers/Microsoft.Security/automations/_name_?api-version=2019-01-01-preview"

[benc-uk]

Note the use of azuresdkhacks package to workaround an issue with the Azure SDK for Go, the reasons are explained in the source, the root cause is covered in this issue Azure/azure-sdk-for-go#12634

[jackofallops]

Hi @benc-uk
Thanks for this PR, looking really good so far, some comments and questions below.

Also, following the thread it sounds like we should wait for SDK 47 before taking this forward so the overrides and change to go.mod can be removed? I'll take a look at that asap.

[benc-uk]

Hi @benc-uk
Thanks for this PR, looking really good so far, some comments and questions below.

Also, following the thread it sounds like we should wait for SDK 47 before taking this forward so the overrides and change to go.mod can be removed? I'll take a look at that asap.

Yes I think waiting for v47 of the SDK is better and then I could remove my workaround from the azuresdkhacks package, there's a PR for getting v47 added in #8865

[benc-uk]

Hi @jackofallops I know we were waiting on updating to the Go SDK v47+ before merging this, has there been any progress on that front?

[jackofallops]

Hi @jackofallops I know we were waiting on updating to the Go SDK v47+ before merging this, has there been any progress on that front?

Hi @benc-uk - Yes, we've had some churn on the SDK, it's now at v48.1.0, if you'd like to rebase this and review the sdkhacks situation as discussed above, and flag me for review again I'll get to it asap.

[benc-uk]

Thanks, I just spotted the SDK had been upgraded so I'm going to re-test my branch against the latest master and with the sdkhacks workaround removed

[benc-uk]

@jackofallops - I think we're in decent shape, I've removed the hack workaround and it all seems good & all my acceptance tests pass

[tombuildsstuff]

Tests look good:

[ghost]

This has been released in version 2.37.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.37.0"
}
# ... other configuration ...

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!