[FR] Handle Cases Where Kibana Duplicates Action Connectors

[eric-forte-elastic]

Repository Feature

Detections-as-Code (DaC) - (primarily custom rule management)

Problem Description

From one of our community members:

Object ID issues when exporting/importing between two spaces. Action connectors and exception lists have unique IDs in each space. We would like to have custom rules with action connectors in one repository and import/export them between both spaces to keep the spaces in sync. This is currently creating duplicate connectors when importing and duplicate configurations when exporting, due to the ID differences between spaces. Sharing the connector and exception list objects between spaces could solve this, but does not seem to be possible.

Context:
For the object ID issues, this is a shortcoming of the current implementation. It will be an issue if you are intending to create action connectors in 2 separate places. When updating/overwriting an action connector, Kibana generates a new ID for it, effectively decoupling it from what is in your repo. The primary issue is if we were to hash the contents of the connector to determine the ID in order to prevent duplicates, this will only work if the connector does not change. If the connector changes, we have no link between the old and the new connector. Then, we will then have to assume that it is a new connector (in effect the current default behavior).In the meantime, one could use custom tooling around the current implementation to have unique names for each connector and tie them together that way from Kibana space to Kibana space. However, one would have to enforce that through the custom tooling as Kibana allows for duplicate names for connectors (See image)

Desired Solution

No response

Considered Alternatives

Generally speaking this is a Kibana issue; however, a DaC workaround could be to delete action connectors associated with any rules being overwritten before overwriting them. This is a fairly large workaround, so it is very likely better to be addressed on the Kibana side.

Additional Context

No response