[Alerting][Enhancement] Allow configuration of the user/role that alerts are written on behalf of

[spong]

This enhancement request is the result of a recent support ticket (https://github.com/elastic/sdh-security-team/issues/720#issuecomment-1721665672) where the user wants to leverage ingest pipelines on the alerts index to re-route alerts to a custom index. This worked in 7.x in the previous Security Solution implementation as it would write alerts on behalf of the current user, however now in 8.x we're writing alerts on behalf of the kibana_system user, which is immutable, and so cannot be updated to write to custom indices.

With the ingest pipeline below configured on the alerts index, rules will fail when writing alerts as the kibana_system user will not have the adequate write privileges:

  "re-route-alerts-pipeline" : {
    "description" : "Pipeline that re-routes alerts to a custom index",
    "processors" : [
      {
        "set" : {
          "field" : "_index",
          "value" : "custom-alerts-index"
        }
      }
    ],
    "version" : 100
  },

In this instance a logstash solution was not feasible, and there were performance concerns with regards to leveraging an index action on all rules. Adding some sort configuration like this to ensure the functionality of ingest pipelines like the above would work with the user's current workflow, but additional options for achieving this result can be considered.

Note: the current workaround here is to create a custom index that the kibana_system user can write to, which ends up being a Kibana System Index e.g. .alerts-alternate-alias. Users should not be creating and managing their own Kibana System Indices, but this is the only workaround at the moment.

[elasticmachine]

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