-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand beats_system role privileges #40876
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 |
new String[] { "monitor", MonitoringBulkAction.NAME}, | ||
new RoleDescriptor.IndicesPrivileges[]{ | ||
RoleDescriptor.IndicesPrivileges.builder() | ||
.indices(".monitoring-beats-*").privileges("create_index", "write").build() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
is(false)); | ||
assertThat(beatsSystemRole.indices().allowedIndicesMatcher(CreateIndexAction.NAME).test(index), is(true)); | ||
assertThat(beatsSystemRole.indices().allowedIndicesMatcher(IndexAction.NAME).test(index), is(true)); | ||
assertThat(beatsSystemRole.indices().allowedIndicesMatcher(DeleteAction.NAME).test(index), is(true)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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/bulk
API. When Security is enabled this API call requires thecluster:admin/xpack/monitoring/bulk
privilege. The built-inbeats_system
role 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 _bulk
API. When Security is enabled this API call requires theindices: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-levelwrite
andcreate_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.