Expand beats_system role privileges#40876
Conversation
|
Pinging @elastic/es-security |
|
Pinging @elastic/es-core-features |
|
They way monitoring works and is configured in Beats, this change makes sense. It creates the least user-disruption. What about the template/index mapping? Is it setup correctly if Beats uses the bulk API? |
The monitoring plugin in Elasticsarch sets up the monitoring index templates. So as long as the cluster that Beats is shipping to has |
There was a problem hiding this comment.
Can we make this create instead of write ?
That gives the ability to index documents (including overwriting existing documents), but not call the update or delete APIs.
I believe that's sufficient for your purposes, and would get us closer to having least privilege users & roles.
There was a problem hiding this comment.
Thanks, indeed create instead of write is sufficient here as the .monitoring-beats-* indices are meant to be append-only and the create privilege allows for bulk indexing as well.
Fixed in 6bf4d8b4756.
There was a problem hiding this comment.
If you're happy with my suggestion above, then this will need to be false.
348390b to
6bf4d8b
Compare
811b163 to
d9e4cb0
Compare
|
@tvernum I made the change you suggested. This is ready for your review again. Thanks! |
Traditionally we have [recommended](https://www.elastic.co/guide/en/beats/filebeat/current/monitoring.html) that Beats send their monitoring data to the **production** Elasticsearch cluster. Beats do this by calling the `POST _monitoring/bulk` API. When Security is enabled this API call requires the `cluster:admin/xpack/monitoring/bulk` privilege. The built-in `beats_system` role has this privilege. [Going forward](elastic/beats#9260), Beats will be able to send their monitoring data directly to the **monitoring** Elasticsearch cluster. Beats will do this by calling the regular `POST _bulk` API. When Security is enabled this API call requires the `indices:data/write/bulk` privilege. Further, the call has to be able to create any indices that don't exist. This PR expands the built-in `beats_system` role's privileges. Specifically, it adds index-level `write` and `create_index` privileges for `.monitoring-beats-*` indices. This will allow Beats users to continue using the `beats_system` role for the new direct monitoring route when Security is enabled.
Traditionally we have [recommended](https://www.elastic.co/guide/en/beats/filebeat/current/monitoring.html) that Beats send their monitoring data to the **production** Elasticsearch cluster. Beats do this by calling the `POST _monitoring/bulk` API. When Security is enabled this API call requires the `cluster:admin/xpack/monitoring/bulk` privilege. The built-in `beats_system` role has this privilege. [Going forward](elastic/beats#9260), Beats will be able to send their monitoring data directly to the **monitoring** Elasticsearch cluster. Beats will do this by calling the regular `POST _bulk` API. When Security is enabled this API call requires the `indices:data/write/bulk` privilege. Further, the call has to be able to create any indices that don't exist. This PR expands the built-in `beats_system` role's privileges. Specifically, it adds index-level `write` and `create_index` privileges for `.monitoring-beats-*` indices. This will allow Beats users to continue using the `beats_system` role for the new direct monitoring route when Security is enabled.
Traditionally we have [recommended](https://www.elastic.co/guide/en/beats/filebeat/current/monitoring.html) that Beats send their monitoring data to the **production** Elasticsearch cluster. Beats do this by calling the `POST _monitoring/bulk` API. When Security is enabled this API call requires the `cluster:admin/xpack/monitoring/bulk` privilege. The built-in `beats_system` role has this privilege. [Going forward](elastic/beats#9260), Beats will be able to send their monitoring data directly to the **monitoring** Elasticsearch cluster. Beats will do this by calling the regular `POST _bulk` API. When Security is enabled this API call requires the `indices:data/write/bulk` privilege. Further, the call has to be able to create any indices that don't exist. This PR expands the built-in `beats_system` role's privileges. Specifically, it adds index-level `write` and `create_index` privileges for `.monitoring-beats-*` indices. This will allow Beats users to continue using the `beats_system` role for the new direct monitoring route when Security is enabled.
|
@ycombinator This change is on 7.3 already so I'm assuming there is nothing left to backport and removed the backport pending label. |
Traditionally we have recommended that Beats send their monitoring data to the production Elasticsearch cluster. Beats do this by calling the
POST _monitoring/bulkAPI. When Security is enabled this API call requires thecluster:admin/xpack/monitoring/bulkprivilege. The built-inbeats_systemrole has this privilege.Going forward, Beats will be able to send their monitoring data directly to the monitoring Elasticsearch cluster. Beats will do this by calling the regular
POST _bulkAPI. When Security is enabled this API call requires theindices:data/write/bulkprivilege. Further, the call has to be able to create any indices that don't exist.This PR expands the built-in
beats_systemrole's privileges. Specifically, it adds index-levelwriteandcreate_indexprivileges for.monitoring-beats-*indices.This will allow Beats users to continue using the
beats_systemrole for the new direct monitoring route when Security is enabled.