Limit the alerts-as-data fields available for alert summaries

[mikecote]

Meta: #143200

We should filter out the kibana.* fields from being exposed to rule actions. However, by doing so, I don't think ECS will contain sufficient information for users to iterate through the alerts and provide a brief overview of each. We should create and approve an explicit list of kibana.* fields that we will allow and filter the rest of the kibana.* fields out.

The filtering should happen within the rule registry in the work done by #143374.

Conversation thread leading to this issue: #143376 (comment).

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[mikecote]

Note that we don't need kibana.alert.rule.* because rule is passed in directly as a context variable (ex: {{rule.id}}) so it doesn't need to be accessed via {{alerts.new[x].kibana.alert.rule.id}}. However, we could make sure the rule object contains what is necessary.

[mikecote]

To facilitate knowing what fields, let's use the list of proposed standardized fields (https://docs.google.com/document/d/1qNagq5Je_77WM91MBweZfGKbM93BIdgyOGChlCtPzYc/edit). Maybe we leave kibana.alert.rule.* in so the structure matches alerts-as-data as much as possible..

[mikecote]

The filtering should happen within the rule registry in the work done by #143374.

Re-adding blocked label. On second thought, I don't think we should do this at the rule registry level. We'll have to keep existing security solution rules backwards compatible by injecting a mustache variable context.alerts which should have access to all the fields. We can implement this filter within the framework once we make use of the getSummarizedAlerts API.

[mikecote]

Closing as no longer needed.