Granting kibana_system reserved role access to "all" privileges to .adhoc.alerts* and .internal.adhoc.alerts* indices

[e40pud]

Parent ticket: https://github.com/elastic/security-team/issues/12484

Summary

We'd like to add privileges to a new set of indices to the kibana_system role. The reason for that is we need to have different naming schema for the manually generated attack discovery alerts index aliases and backing indices pointing to these aliases.

Adding for the new "Attack Discovery Scheduling" feature that utilizes alerts as data and a reserved index to write alerts. The attack discovery scheduling feature requires a possibility to generate alerts without running an existing (registered in alerting framework) rule and for that we are writing adhoc generated alerts to a separate index (than normal alerts) so they won't show up with standard .alerts* queries, but still need the same permissions as "normal" alert indices.

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[elasticsearchmachine]

Hi @e40pud, I've created a changelog YAML for you.

[jeramysoucy]

Are these indices created/owned by Kibana?

[e40pud]

Correct

[jeramysoucy]

Question - are these indices created and managed by Kibana, or another stack component (e.g. ES, an integration, etc.)?

Also, we prefer rather than assigning "all", that specific privileges are enumerated when augmenting the kibana_system role. For example, kibana_system likely does not need the ability to perform cross-cluster replication on these indices, and "cross_cluster_replication" is granted by "all". Ideally, the minimum required privileges should be granted.

The full list of index privileges for reference: https://www.elastic.co/docs/reference/elasticsearch/security-privileges#privileges-list-indices
Keep in mind also that some privileges cascade, like the "manage" index privilege which grants many of the other manage_* index privileges.

[e40pud]

Question - are these indices created and managed by Kibana, or another stack component (e.g. ES, an integration, etc.)?

Also, we prefer rather than assigning "all", that specific privileges are enumerated when augmenting the kibana_system role. For example, kibana_system likely does not need the ability to perform cross-cluster replication on these indices, and "cross_cluster_replication" is granted by "all". Ideally, the minimum required privileges should be granted.

The full list of index privileges for reference: https://www.elastic.co/docs/reference/elasticsearch/security-privileges#privileges-list-indices Keep in mind also that some privileges cascade, like the "manage" index privilege which grants many of the other manage_* index privileges.

@jeramysoucy thanks for the review. I updated the list of privileges to be able to create, manage, read and write the index.

[jeramysoucy]

@e40pud Thanks for updating this! The last thing I'd like to ask, is about the manage privilege, which inherently includes all of these privileges:

• manage_data_stream_lifecycle
• manage_follow_index
• manage_ilm
• manage_leader_index
• monitor
• maintenance
• auto_configure

Aiming for the minimum necessary privileges, could we include just a subset of these? If not, could you provide justification to include them? Sorry to have to ask. We like to be as thorough as we can when changing this role.

[e40pud]

I went through the ES apis that we use to work with this indices and here is the list of all of them:

1. Simulate an index (API, Usage in kibana)
2. Simulate index template (API, Usage in kibana)
3. Create or update an index template (API, Usage in kibana)
4. Get data streams (API, Usage in kibana)
5. Create a data stream (API, Usage in kibana)
6. Get aliases (API, Usage in kibana)
7. Get index information (API, Usage in kibana)
8. Create an index (API, Usage in kibana)
9. Create or update an alias (API, Usage in kibana)
10. Get index templates (API, Usage in kibana)
11. Update field mappings (API, Usage in kibana)
12. Create or update a lifecycle policy (API, Usage in kibana)
13. Create or update a component template (API, Usage in kibana)
14. Update index settings (API, Usage in kibana)
15. Search (API, Usage in kibana)
16. Bulk index or delete documents (API, Usage in kibana)

Regarding the manage privilege we need it because when we create the index we also specify the alias for it:

esClient.indices.create({
  index: indexPatterns.name,
  aliases: {
    [indexPatterns.alias]: {
      is_write_index: true,
    },
  },
})

and according to the create_index privilege documentation manage privilege is required.

Privilege to create an index or data stream. A create index request may contain aliases to be added to the index once created. In that case the request requires the manage privilege as well, on both the index and the aliases names.