[datadog_security_monitoring_rule] Add Terraform Support for Signal Correlation Rules

[clementgbcn]

Description

This PR updates the Terraform provider to support Signal Correlation rules.

It replaces #1591 which was not backward compatible.

It impact the resources/data:

• resource_datadog_security_monitoring_rule
• data_source_datadog_security_monitoring_rules

To be backward compatible, the fields which are specific to Signal Correlation rules (i.e., ruleId, defaultRuleId, correlatedByFields, correlatedQueryIndex) are populated in a different sub list Schema called signal_query.
Since query is a List that could have multiple elements, it is not possible to enforce a DistinctsWith.

Since the Go struct SecurityMonitoringRuleResponse does not implement a common interface for SecurityMonitoringStandardRuleResponse and SecurityMonitoringSignalRuleResponse, most of the methods have been specialised in spite of having common code.

Additionally, this PR homogenises the way the payloads are populated by using the Setters instead of directly accessing the attributes in security_monitoring. It addresses remarks from previous PR about wording.

How do these changes impact current model

Up to now, Datadog Security Monitoring has been supporting one common type of rule whose Terraform schema is

resource "datadog_security_monitoring_rule" "log_detection_example" {
  name = "My log detection rule"
  message = "Rule triggered"
  enabled = false
  has_extended_title = true
  query {
	  name = "first"
	  query = "does not really match much"
	  aggregation = "count"
	  group_by_fields = ["host"]
  }
  case {...}
  options {...}
  filter {...}
  tags = [...]
}

This schema is not modified for existing rule type.

On the other hand, signal correlation rules will have a similar schema which will differ by its queries and its type:

resource "datadog_security_monitoring_rule" "signal_correlation_example" {
  name = "My Signal Correlation rule"
  message = "Important attack in progress"
  enabled = false
  has_extended_title = true
  signal_query {
	  name = "first"
	  rule_id = "lc2-ol2-ue0"
	  aggregation = "event_count"
	  correlated_fy_fields = ["host"]
          correlated_query_index = ""
  }
  signal_query {
	  name = "first"
	  rule_id = "fgt-40m-kiv"
	  aggregation = "event_count"
	  group_by_fields = ["host"]
          correlated_query_index = "1"
  }
  case {...}
  options {...}
  filter {...}
  tags = [...]
}

A check was implemented in Terraform to prevent users from having two populated lists (i.e. query and signal_query).

correlated_query_index

In spite of being an index (thus an integer), the Terraform Schema uses a string to represent it because this value can be empty.
Having:

• correlated_query_index=0: Means correlate on the projected attributes of the first query of the correlated rule
• correlated_query_index="": Means correlate on the non-projected per query attribute of the correlated rule.
  Since TypeInt object does not support a nil value as a Default value, we decided to use a string which is converted to an integer if it is not empty.

[maycmlee]

👍 for docs

[skarimo]

NIT: I think it would be better to differentiate based on wether query or signal_query field is set.

[clementgbcn]

However, the next instruction is about getting the id of the response by accessing the non null field of the response. Therefore, it seems to me that this check is mandatory (and then sufficient) for assigning the id.

[skarimo]

Why not use TF validation schema helpers such as ConflictsWith properties instead?

[clementgbcn]

I tried but it was not working since, as stated in the documentations:

// Only absolute attribute paths, ones starting with top level attribute
// names, are supported. Attribute paths cannot be accurately declared
// for TypeList (if MaxItems is greater than 1), TypeMap, or TypeSet
// attributes. To reference an attribute under a single configuration block
// (TypeList with Elem of *Resource and MaxItems of 1), the syntax is
// "parent_block_name.0.child_attribute_name".

In our case, it is a TypeList whose MaxItems is greater than 1.

[pietrodll]

Nice job 👌 There's a typo in the aggregation type description, otherwise only nits 😄

[pietrodll]

Very nice 🎉 only a couple of nits

[pietrodll]

This code seems useless as metrics is not defined on signal_query.

Suggested change

	if v, ok := query["metrics"]; ok && v != nil {
	if tfMetrics, ok := v.([]interface{}); ok && len(tfMetrics) > 0 {
	metrics := make([]string, len(tfMetrics))
	for i, value := range tfMetrics {
	metrics[i] = value.(string)
	}
	payloadQuery.SetMetrics(metrics)
	}
	}

[clementgbcn]

✅ (in all places)

[pietrodll]

I think these interfaces should be private, as they are utilities to factorize code.

[clementgbcn]

✅

[pietrodll]

🎉