Beats: Proposals For More Restrictive Privileges

[MorrieAtElastic]

This request for a clarification of privileges needed to operate various Beats products arose out of a Support ticket and subsequent internal discussions with developers.

The essential question is what are the minimum set of privileges necessary to operate Beats products in various pipelines, and the motivation for the discussion as to do with whether the documented privileges really are necessary at all times. At least some of the issues to be discussed here have been touched on in #4826.

User has made the following proposal for the minimum set of privileges required for Beats users:

On indexes created by beats: create_index, index

And the following cluster level permissions: manage_index_templates, manage_ingest_pipelines, monitor

-note that "write" privilege on the indexes is not included.

User's motivation for this restrictive set of privileges is based on the fact that he maintains a cluster being accessed by many hundreds of beat client machines with many hundreds of users with various levels of system privileges on those client machines. User is concerned about unauthorized access/deletion/corruption of data by external users.

Developer's initial response to this proposal was to add to it the suggestion that Beats privileges could be split into 2 different sets of privileges: those necessary for setting up the specific Beat environment and those required for daily operation of beat processes:

Beats modules setup index templates and Filebeat sets up pipelines in Ingest Node. For the setup step you need to have the correct permissions. Having these rights an user might be able to remove/overwrite templates and pipelines, indeed.

Once everything is setup Beats only require write permissions. As Beats do rely on Elasticsearch to create the index on write, create permissions will also be required.

One can separate the setup phase from the actual event publishing. Use the filebeat setup command to install your modules ingest pipelines and prepare the templates. This is a one-time command. Once it successfully returns setup is completed. Now the beat can be run without any setup required. This way one can have 2 different users configured in Elasticsearch, one for setup and another one for indexing.

Obviously, this discussion has not touched on any changes in privileges which may be coming in 6.6 or 7.0, but the basic motivation is reasonable: shall we "officially" (as in endorsing and documenting the proposal) split Beats privileges into Setup and Operation privilege sets - possibly provided to different users), and can we identify the minimum set of privileges required for operations?

[andrewkroh]

+1 for changing write to index in the documentation.

For reference here's a link to the relevant docs: https://www.elastic.co/guide/en/beats/filebeat/current/beats-basic-auth.html#

[willemdh]

Something else I was worrying about =>Only Filebeat actually needs 'manage_ingest pipelines' cluster privilege correct? But that privileges could possible allow an insider threats to update any ingest pipeline resulting in all kinds of unwanted situations.

Thoughts? Is there a way to avoid the need to assign the 'manage_ingest pipelines' to all Filebeat users? Could we, like Morris suggest, create 1 setup Filebeat on a trusted server with 'manage_ingest pipelines' and assign a Filebeat user without 'manage_ingest pipelines' to all other servers?

[ph]

Thoughts? Is there a way to avoid the need to assign the 'manage_ingest pipelines' to all Filebeat users? Could we, like Morris suggest, create 1 setup Filebeat on a trusted server with 'manage_ingest pipelines' and assign a Filebeat user without 'manage_ingest pipelines' to all other servers?

You can already do that by using the setup subcommand, so you could do it before deploying any beats with a specific user and role.

We will also need to think the privileges in the context of ILM because to create them require to use a manage_ilm cluster role

[dedemorton]

I wonder if we're being too prescriptive in our docs by providing step-by-step instructions to create specific users and roles for Beats. Maybe we just need to list the features or actions that require specific privileges, and leave it up to whoever is setting up security for their org to decide which users/roles to create.

Our docs make it very easy to set up security quickly, but it sounds like the roles we tell users to create might not be restrictive enough. I'd like to get this fixed in the docs. I've been kicking this can down the road for quite awhile.

[dedemorton]

Can we distill this conversation into a list of roles that we want to recommend to users and the privileges that each role should have? I'd like to clean up the docs, but want to make sure we have agreement here. Do we need to meet to discuss?

@andrewkroh @ph @urso @andrewvc

[dedemorton]

The following comments were offered by @urso during a discussion about a related pull request: https://github.com/elastic/beats/pull/10449/files#r255850589. Since that PR has already been merged, I want to make sure his comments get preserved and addressed.

Full text of the comment:

Well, in the end it is up to the user to see if they want separate roles or users. ES has a builtin beats_system role and user, but this one is used for monitoring only. Users are not advised to reuse beats_system for more than monitoring.

I'd prefer not to document actual roles in the first place, but the different means how (and when) Beats interact with the Elastic Stack. Interactions roughly encompass:

• setup
• publish monitoring
• publish events

At optimum these roles are separated and setup is executed only once and fully independent from actually running a Beat. If setup is not executed in isolation we need privileges for "publish events" and "setup" to be owned by the same user.

Depending on the Beat, setup can actually entail different tasks (well, to date only filebeat is the exception).
Setup tasks are:

• Install template. Requires manage_index_templates (cluster)
• (filebeat only) Install ingest node piplines. Requires manage_ingest_pipelines (cluster). I'm not sure about manage_pipeline (cluster).
• Configure ILM policy. Requires manage_ilm (cluster)
• (If ILM is enabled) Create initial index. Requires create_index (index), manage (index)
• Create Kibana index mapping
• Upload dashboards via Kibana API
• (filebeat only) Enable ML modules via Kibana API

TBH. I'm not sure manage (cluster) is even required, but I never tried without.

Writer requires:

• create_index (index) . If ILM is enabled create_index might not be required, but not sure if that is really the case.
• write (index).
• If ILM is enabled we still check if policy and alias is available (I never tried with security enabled, we have to test):
  • view_index_metadata (index)
  • read_ilm (cluster)

In the end this indeed calls for {beatname_uc}_setup, beats_system, and {beatname_uc}_write users + roles.

[dedemorton]

Based on the comments submitted by @ urso ^^, I propose the following changes to the existing content:

• Delete the step-by-step topics that describe how to create users and roles: https://www.elastic.co/guide/en/beats/metricbeat/current/beats-basic-auth.html and https://www.elastic.co/guide/en/beats/metricbeat/current/beats-user-access.html
• Create a new reference-style topic called something like "Filebeat users and roles". The topic will
  • Provide a general discussion of the types of users who need credentials based on what the users need to do: set up Beats, publish monitoring data, publish events.
  • For each type of user, lists specific tasks (install template, load dashboards, etc) that require credentials.
  • For each task, identify any privileges or built-in roles that the user must have to perform that task.

The information should be in reference format--easy to scan--and point to the Stack security docs for more information about setting up security.

The goal here is to give users just the info they need to implement a security strategy that works for their org.

If that sounds good with everyone, I will start working on the docs. I think I'll need help getting the full list of the most restrictive privileges for each task.

[willemdh]

@dedemorton

Writer requires:

• create_index (index) . If ILM is enabled create_index might not be required, but not sure if that is really the case.
• write (index).
• If ILM is enabled we still check if policy and alias is available (I never tried with security enabled, we have to test):
  • view_index_metadata (index)
  • read_ilm (cluster)

Why is it again suggested to give write permissions, while index should be sufficient? That was actually the main reason I created the original case...

[karenzone]

@karenzone (note to self): Good stuff here! Consider a similar approach for Logstash per DeDe's suggestion.

[dedemorton]

@willemdh I was just pasting in the response from a related PR to make sure the comments aren't lost. Rest assured that I will make sure the docs reflect the most restrictive privileges required.

[MorrieAtElastic]

I am reopening this proposal on behalf of the customer for whom I initially opened it 6 months ago.

Customer has now migrated his clusters to 7.2.0, and he is horrified at the required privileges now required for Beats users. Basically the entire result of this exercise has been that more privilges are required of Beats users in 7.2.0, not less, and the resulting implications for security are exactly the opposite of what customer was hoping for.

Example comments:

Does Elastic really requires us to give manage privilege on the impacted Beats indices for the configured user?

To be honest Im' not sure where Elastic is going with giving such high privileges to Beats users. Didn't anyone think this through? The principle of least privilege should be applied. Giving beats users 'manage' privilege which actually allows deletion of the indices doesn't seem like a good idea??

So is there a way to not give the beats user 'manage' privilege on the beat indices, but still make use of ilm?

Is this only required to read the aliasses, maybe a new index privilege read_alias would be a solution? ... What else does a Beats need to do? If you think about all it should do is index. All other privileges should not be required and that functionality should be handled the Elasticsearch / Kibana side.

To be honest, if nobody at elastic sees there is a problem with giving 'manage' privileges to beats users, then I'm really worried.... You can't trust endpoints these days..., that should be common knowledge.

And frankly, I believe customer has a point. And most of the additional privileges are required only for ILM. Perhaps we can rethink this?

[crashdump]

To be honest, if nobody at elastic sees there is a problem with giving 'manage' privileges to beats users, then I'm really worried.... You can't trust endpoints these days..., that should be common knowledge.

And frankly, I believe customer has a point. And most of the additional privileges are required only for ILM. Perhaps we can rethink this?

I was very happy to see that Elastic were now providing SIEM capabilities – out of the box – but for the reasons above, we will not be able to proceed.

Endpoints should not be able to read/modify any data server side, only submit it.

[dedemorton]

@MorrieAtElastic I think you meant to re-open this issue, no? I've pinged @urso for a response from the development team. I think I've resolved the doc-related problem (the docs now show the privileges required for specific user tasks), but in the process I've exposed some areas where we need to improve our security strategy.

[urso]

The documentation splits up the privileges into multiple needs:

• Initial setup
• monitoring
• event publishing
• kibana users

When using Beats I like to split the process into 2 phases. First the setup phase, then the data collection phase. Each requires a different set of credentials. The initial setup privileges are only required for the first phase. Thereafter never again. Hence I'd recommend to have 2 users. One admin user preparing the stack and one beats user for publishing events. Actually one could add another user for publishing monitoring data only. Having multiple users will allow us to grant the least required privileges per user/scenario.
At best setup and data collection are run from different machines and/or by different people.

The admin user will be used for the setup phase only. Assuming we have installed filebeat via a debian package, want to reuse the configuration file, but overwrite user settings without having to change the configuration file for setup only we can run: filebeat setup -c /etc/filebeat/filebeat.yml -c admin.yml. The admin.yml file adds or overwrites settings in filebeat.yml for index/template/ilm/dashboard/ingest pipelines setup. We can even disable/remove most setup settings from filebeat.yml.

Once the stack is prepared, we can run Beats with a reduced set of privileges.

Without ILM Beats will need to create indices daily. Which means we need the create_index and write privileges at least. Still Beats try to figure out if the template is installed or not. If it is not installed, Beats will try to install it. Here we have 3 options:

1. allow Beats user to install the template. Requires Index template setup privileges
2. allow Beats to to check if the template is installed only. In this case Beats wil try to install it, but fail. This process is subject to exponential backoff. Once the template becomes available, Beats will continue with sending events. This requires setup.template.enabled: true, with monitor privileges only.
3. disable templates check in Beats and hope for the best. This assume <beatname> setup was run before and the stack is in a good state. This can be done by setting setup.template.enabled: false. In this case we need write and create_index privileges only. If templates have not been setup correctly, we might end up with invalid mappings, though.

With ILM we use a write alias. In presence of ILM, it is Elasticsearch creating new indices. The privileges for the rollover process in Elasticsearch should be based on the user/role that used to prepare ILM. Here again we have the 3 options:

1. Allow Beats user to prepare ILM. This requires us to install templates, ILM policies, aliases and create the first index. Quite a many privileges that need to be exposed here.
2. Allow Beats to check if ILM is available and configured. Again, beats will fail to install all resources, but also wait for them to become available. This requires read_ilm to check if policy is setup and monitor, read_ilm, or view_index_metadata (I think) in order to check if the alias is available.
3. Disable all checks, but make sure filebeat uses the write alias (assuming everything has been setup in advance): setup.template.enabled: false, setup.ilm.enabled: true, setup.ilm.check_exists: false, setup.ilm.overwrite: false. If the alias is available, only having write privileges should be enough. Without create_index privileges indexing should fail if the alias does not yet exist (which is a must, otherwise we will have a wrongly configured index, which should be an alias). In this scenario beats will retry (with exponential backoff), until someone made the alias available by running <beatname> setup.

Without ILM I'm in favor of option 2 (write, create_index, and monitor privileges). With ILM I'm in favor of option 3 (write privileges only).

[urso]

Chatting with @tvernum we should not use write, but index privileges only. write allows indexing + delete + delete-by-query + update + update-by-query + reindex, this is indeed too much for a beats-writer only user.

[willemdh]

"we should not use write, but index privileges only. write allows indexing + delete + delete-by-query + update + update-by-query + reindex, this is indeed too much for a beats-writer only user."

Exactly what I'm trying to say since 22/01...

Also

Please do not require 'manage' privilege on *beat indices...

Also for Filebeat requiring "manage_pipeline" on cluster level is not really optimal... Imho pipelines should be managed from Kibana and never from agent / client side. A simple gui with a way to import 'official ingest pipelines' would be so much better (Same for dashboard management)?

But if I read @urso 's post correctly, it should be already possible to make ilm work without manage privilege? (Actually tried this and didn't immediately got it to work, but I had too many other upgrade issues to dedicate enough time to investigate properly, so for now I disabled ilm for all beats indices)

[dedemorton]

@urso Not sure if there is an underlying bug at play here, but when I I try the setup you describe--an admin user with all required privileges that sets up the beat (index template, dashboards, index management, etc) and a different user with index on filebeat-* that publishes events), I still get the following error when using ILM. If I grant manage on `filebeat-*, the error goes away:

2019-07-11T17:09:16.639-0700	ERROR	pipeline/output.go:100	Failed to connect
to backoff(elasticsearch(https://3e43d10252e44c9f866c919a8345866d.us-
west1.gcp.cloud.es.io:9243)): Connection marked as failed because the onConnect
callback failed: failed to check for alias 'filebeat-7.2.0': (status=403) : 403 Forbidden:

I also get the following error (even when filebeat.overwrite_pipelines: false) if I don't give manage_pipeline on cluster to the user:

2019-07-11T17:04:37.949-0700	ERROR	fileset/factory.go:136	Error loading pipeline:
1 error: Error loading pipeline for fileset system/auth: couldn't load pipeline: couldn't load
json. Error: 403 Forbidden: {"error":{"root_cause":[{"type":"security_exception","reason":
"action [cluster:admin/ingest/pipeline/put] is unauthorized for user 
[filebeat_publisher]"}],"type":"security_exception","reason":"action 
[cluster:admin/ingest/pipeline/put] is unauthorized for user [filebeat_publisher]"},"status":403}. 
Response body: {"error":{"root_cause":[{"type":"security_exception","reason":"action 
[cluster:admin/ingest/pipeline/put] is unauthorized for user 
[filebeat_publisher]"}],"type":"security_exception","reason":"action 
[cluster:admin/ingest/pipeline/put] is unauthorized for user [filebeat_publisher]"},"status":403}

Can you try to reproduce this issue to see if it's a bug?

[urso]

@dedemorton Thanks for testing. I will run some more tests and share my configs if successfull. If it doesn't work with minimal privileges, then I'd consider this a bug.

[cwurm]

Sorry to jump in here, but I've done some testing since this has come up in discuss.

@dedemorton You can make the first error go away by setting the more restrictive view_index_metadata instead of manage. We are not getting the usual error message from Elasticsearch there, I've submitted a fix.

The second error seems more complicated. In the code, it looks like there are a number of places where we are loading pipelines but not guarding for overwrite_pipelines: false. The fix there looks harder, so I'll leave that to people more familiar with the code.

To answer the question in the forum I've done testing on which privileges are required with the default Beats configuration (ILM enabled, etc.). I started with a user with no privileges, and slowly added more every time I ran into an error. The goal was to come up with what a beats_setup and a beats_write role should look like. This is what I've come up with:

Setup (beats_setup)

1. monitor
2. manage_ilm
3. manage_index_templates
4. manage (on all indices)
5. manage_ingest_pipelines / manage_pipeline (both work, not sure what the difference is)
6. + kibana_user (separate role to load Kibana dashboards)

4 is a real shame, unfortunately, create_index is not enough to create aliases :-( (EDIT: And we need to create an alias to set up ILM.)

Run (beats_write)

1. monitor
2. read_ilm
3. manage_index_templates
4. view_index_metadata (on all indices)
5. index / create (on all indices - both work, not sure what the difference is)

There are no built-in roles at the moment that have these privilege combinations. I think it would be useful to add them. At least to document what is required.

[tvernum]

index / create (both work, not sure what the difference is)

create cannot call the _update API, but index can.

create can still overwrite docs (security doesn't currently distinguish between an op_type of create vs index), but cannot perform the implict get-modify-put operation of _update.

[urso]

I did some more testing with filebeat and identified a few possible roles, which are to be used based on configs and the actual scenario.

So other can play with it, I did prepare a gist with some configs, docker-compose file, and kibana console script to load the different roles and users.

Dedicated role types I created are:

• beats_setup: For admin user.
  • Cluster permissions: manage_index_templates, monitor, manage_ilm, manage_ml, manage_ingest_pipelines (filebeat only).
  • Index permissions: "create_index", "manage"
• beats_writer: Beats user indexing events. ILM enabled and default beats settings). This user checks if ILM policy, alias, and template exist, but will not be able to install these. Will error, until cluster has been configured.
  • Cluster permissions: monitor, read_ilm, manage_index_templates.
  • Index permissions: index, view_index_metadata
• beats_indexer: Beats user indexing events. ILM enabled. Beats settings have been trimmed down to not check for ILM policy or template. The beat will still check for the existance of the write alias on startup and refuse to index if this one is missing.
  • Cluster permissions: monitor (to check if alias exists).
  • Index permissions: index, view_index_metadata
• beats_index_writer: For Beats users not making use of ILM.
  • Cluster permissions: monitor, read_ilm, manage_index_templates.
  • Index permissions: index, create_index, view_index_metadata.

Note: beats_writer adds "read_ilm", and "manage_index_templates" to the beats_indexer role.

Depending on organization and beats ownership, I would create per Beat roles in production, and then assign the correct roles to users. Introducing scripts to build those, would also make it easier to create a similar experience for community Beats throughout an organization.

Based on these roles I did test a few scenarios:

Scenario 1: Separate setup + indexing users. With ILM and mostly default settings

• use setup with setup role: filebeat setup -c test.yml -c setup_ilm.yml
• index using default beats settings for template + ILM: rm -fR data && ./filebeat -e -v -c test.yml -c writer.yml

=> 2 users: a) admin user with beats_setup role, and b) writer user with beats_writer role

Scenario 2: Separate setup + indexing users. With ILM, but 'trimmed down' beats configs. No template setup, and no ILM policy setup. The Beat still checks for the existance of the write alias. Beats settings:

setup.template.enabled: false

setup.ilm:
  enabled: true
  check_exists: false
  overwrite: false

• use setup with setup role: filebeat setup -c test.yml -c setup_ilm.yml
• index using default beats settings for template + ILM: rm -fR data && ./filebeat -e -v -c test.yml -c indexer.yml

=> 2 users: a) admin user with beats_setup role, and b) writer user with beats_indexer role

Scenario 3: Separate setup + indexing, but with ILM disabled.

• use setup with setup role: filebeat setup -c test.yml -c setup_index.yml
• index with default beats settings, without ILM: rm -fR data && ./filebeat -e -v -c test.yml -c index_writer.yml

=> 2 users: a) admin user with beats_setup role, b) writer with beats_index_writer role

Note: The writer has permissions to manage templates and create indices.

Scenario 4: Self managed single user with ILM, potentially not running filebeat setup:

• index using default beats settings + ILM: rm -fR data && ./filebeat -e -v -c test.yml -c self_managed.yml

=> 1 user with beats_setup and beats_indexer roles

Scenario 5: Self managed single user without ILM, potentially not running filebeat setup:

• index with default beats settings, without ILM: rm -fR data && ./filebeat -e -v -c test.yml -c index_writer.yml

=> 1 user with beats_index_writer role

Note: Scenario 5 is similar to 3, but without the setup call. The manage_index_templates is rather powerful here. The execution of filebeat setup will only install kibana index pattern, dashboards, ingest pipelines, and ml jobs in addition.

[dedemorton]

@urso I like the idea of automating this somehow. It's a lot to expect readers to parse the various combinations that you show above, and the naming doesn't seem very intuitive.

Could we do some kind of online tool (like elasticsearch-setup-password, but with more functionality)? Instead of just setting passwords, the tool could walk users through a series of questions: Are you using index lifecycle management...central management...machine learning...index pattern...etc... After gathering the necessary info, the script could show some kind of confirmation of the users/roles being created, then create the users/roles and maybe allow the person running the tool to set the initial password.

[cwurm]

I think we should not force new users to learn what ILM, ML, templates, aliases, and the 30+ different privileges are before getting started with Beats securely. Being secure should be easy and as out of the box as possible.

If we had two built-in users and/or roles - one for setup, one for writing/appending - the instructions would be very simple: Run setup once with this user/role, then run all Beats on all your machines with this other user/role.

Looking at @urso's list, the two users/roles covering all scenarios would have these privileges:

• Setup
  • Cluster: monitor, manage_ilm, manage_ml, manage_index_templates, manage_ingest_pipelines
  • Index: create_index, manage
• Writing
  • Cluster: monitor, read_ilm, manage_index_templates
  • Index: create, create_index, view_index_metadata

These users/roles would not just be useful to Beats either, but to all tools ingesting data (e.g. Logstash), and so could have generic names, e.g. something like index_setup and index_append_only. Ideally, we would eventually figure out a way to not allow the latter to overwrite existing data (not possible today).

[dedemorton]

I think we should not force new users to learn what ILM, ML, templates, aliases, and the 30+ different privileges are before getting started with Beats securely.

I totally agree! But if we do provide scripts in the interim, let's make them as easy to use as possible.

[dedemorton]

I've updated the docs (see #12921), but there are some remaining issues that the docs cannot solve. Should I create separate tickets for these issues?

• Writer role seems to require manage_pipeline (or is it manage_ingest_pipelines) even when when you pre-load the ingest pipelines and filebeat.overwrite_pipelines: false.

• We have two privileges that might be duplicates: manage_pipeline and manage_ingest_pipelines. Are they both necessary? If so, how are they different? If they're the same, can we deprecate one?

• We need to make it easier for users to secure Beats. Users should not have to know about beats features to know which privileges are required. One suggestion is to add built-in roles for Beats.

[urso]

I'm not a fan of the idea about a predefined index_setup, and index_append_only roles. The privileges we have are too generous + you would need to set the index privileges to *, which means users having access to this role do have access to all indices in your cluster. We could restrict the set of indices to a known default set, but then we have to ask the user to modify the indices privileges on a built in user in case the user runs non standard beats, or has Beats/Logstash with configured with custom indices.

[andrewvc]

@urso if a user runs non-standard configurations would they be surprised to need to extra work here? Seems like a reasonable ask of the user.

[urso]

@elastic/es-security Maybe Elasticsearch security team can chime in as well?

If we were to prepare an index_append_only user, then we would need to restrict said user to logstash-*, filebeat-*, metricbeat-*, and other default beats by default only. As this would be a built in role, can users just update the role to other indices (and still work correctly after upgrades)?
Personally I'd prefer one role per index/application type.

What makes me a little uneasy about that user is the manage_index_template privileges. Having this privilege an user can create templates for any kind of index. Being able to do so means that attacker having access to this role can create conflicting templates for any index in the cluster, and render indexing to new indices defunct (e.g. after rollover).

[tvernum]

We have two privileges that might be duplicates: manage_pipeline and manage_ingest_pipelines. Are they both necessary? If so, how are they different? If they're the same, can we deprecate one?

They are identical. Two separate PRs added them at almost the same time during the addition on ingest node in the 5.0 release. We will deprecate one.

As this would be a built in role, can users just update the role to other indices (and still work correctly after upgrades)?

No, builtin roles cannot be modified by the user (they are defined in code, there is no update API for them).

We have thrown around the idea of a templated role so that you could somehow (we've never gotten to the point of working out details) apply a "filebeat-ingest" role-template to a custom index.
It's not something we're working on though, and there's lots of unanswered questions (e.g. what if the template changes with a version upgrade, are the roles automatically updated?).

An alternative would be to define product specific privilege names. We haven't done so in the past, but it's open for discussion.
Then you could defined a role with { "cluster" : [ "beats_ingest" ] , "indices" : [ { "names": ["my-beat-index-*"], "privileges":[ "beats_ingest" ] } and not have to worry what those mean.
However, a downside is that it would be hard for security admins to know what they mean - they're just opaque privilege names, so it's hard to audit the access that they grant.

What makes me a little uneasy about that user is the manage_index_template privileges

We're likely to be looking at tighter control over those sorts of cluster objects soon. We can push this use case up to the top priority.

[cwurm]

What makes me a little uneasy about that user is the manage_index_template privileges. Having this privilege an user can create templates for any kind of index. Being able to do so means that attacker having access to this role can create conflicting templates for any index in the cluster, and render indexing to new indices defunct (e.g. after rollover).

I think this is a general problem? Even if scoped to an index pattern, a Beat could disable indexing from all other Beats writing to the same index pattern.

I wonder if we could do without this privilege for writing? setup will already create a template, so there is no need to write it again. The problem at the moment seems to be that to even check if a template exists (using e.g. HEAD _template/auditbeat-7.2.0) we need indices:admin/template/get which comes with manage_index_templates.

However, we could use GET _cat/templates/auditbeat-7.2.0 instead, for which monitor is enough.

[DanRoscigno]

@urso @cwurm @dedemorton :

When I was working through using RBAC for Filebeat I ran with the recommended (from the docs) role for the setup user and setup ran fine. I then used the recommended writer role to run Filebeat to collect logs. Without the manage_index_template priv the Beat failed, so I added it in and created issue #13207

Is there a plan to remove the need for manage_index_template? Either way, could we get the docs updated to include manage_index_template until it is no longer needed? If the plan is to have users restrict the writer user with:

setup.template.enabled: false
setup.ilm.check_exists: false
setup.ilm.overwrite: false 

then could this be reworded from "you can ..." to "Add these lines to filebeat.yml" and put the directive as item 3 in the steps Create a writer role, Assign the writer role, Edit filebeat.yaml

When I am reading the docs I ignore optional stuff until I get things working, and then I go back if I remember. In this case what I thought was optional stuff is not optional, right?

[DanRoscigno]

And if you like, I am happy to write the PR to modify libbeat/docs/security/users.asciidoc to move what I considered to be optional down to step 3.

[dedemorton]

@DanRoscigno That's a good point. I'll make the info an actual step so that users don't overlook it. It's very tricky to document the list of required privileges when that list varies depending on which options users have set in the config. IMO it's not a great user experience.

[cwurm]

An update on this:

After some small changes scheduled to be released in 7.5 (incl. #13847, #13848, #13936) it will be possible to send data from a Beat with only two privileges:

1. The read-only monitor cluster privilege - the lowest cluster privilege there is, that is needed for anything at all, e.g. checking version and health.
2. The append-only create_doc index privilege - this is a new (Add 'create_doc' index privilege elasticsearch#45806) index privilege that is currently scheduled to be available in Elasticsearch 7.5.

This assumes:

1. beatname setup set everything up already using setup privileges.
2. Using ILM - if not, we need create_index.
3. In beatname.yml: setup.ilm.check_exists: false - if true (the default) we need read_ilm and view_index_metadata.
4. Not using any modules requiring ingest pipelines (e.g. in Filebeat) - if using modules with pipelines, we need cluster:admin/ingest/pipeline/get.

This should allow running Beats with minimal, read-only privileges in most situations.

The master docs have been updated to reflect this.

[cwurm]

@tvernum cluster:admin/ingest/pipeline/get does not seem to be included in any built-in, read-only cluster privileges. manage_pipeline/manage_ingest_pipelines are not read-only. Is a read-only cluster privilege (e.g. read_pipeline/read_ingest_pipelines)something we could add to have autocompletion in Kibana?

[tvernum]

@cwurm Absolutely. We won't be able to squeeze it into 7.5, but it's a small enough change that we should get it into a 7.x soon.

This had been listed on our meta-issue for new privileges, but I've opened an explicit issue to track it.

[joaociocca]

Hey, you peeps, while working on this, ever notice Elasticsearch stopping *beat with cluster:admin/ilm/put and cluster:admin/ilm/get?

Exiting: failed to check for policy name 'metricbeat': (status=403) {"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:admin/ilm/get] is unauthorized for user [beats_system]"}],"type":"security_exception","reason":"action [cluster:admin/ilm/get] is unauthorized for user [beats_system]"},"status":403}: 403 Forbidden: {"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:admin/ilm/get] is unauthorized for user [beats_system]"}],"type":"security_exception","reason":"action [cluster:admin/ilm/get] is unauthorized for user [beats_system]"},"status":403}

[DanRoscigno]

Hi @joaociocca , what do you have for setup.ilm.check_exists?
Here is my metricbeat.yml

Here is the info on the proper role and user for writing data (for 7.7, change to the version of Metricbeat you are using as the role has changed recently). Open a discuss.elastic.co conversation and @ mention me if you need more help.

[fholzer]

I have the same issues as @dedemorton, we use a separate user for running filebeat setup or manage things like ILM and ingest pipelines completely on or own, and would like to use a user with very restrictive permissions for filebeat, but it seem no matter what we try, filebeat always tries to read existing ingest pipelines from the cluster:

2021-12-02T14:25:23.576Z        ERROR   [modules]       fileset/factory.go:163  Error loading pipeline: 1 error: error loading pipeline for fileset logstash/log: couldn't load pipeline: couldn't load json. Error: 403 Forbidden: {"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:admin/ingest/pipeline/put] is unauthorized for user [USERNAME]"}],"type":"security_exception","reason":"action [cluster:admin/ingest/pipeline/put] is unauthorized for user [USERNAME]"},"status":403}. Response body: {"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:admin/ingest/pipeline/put] is unauthorized for user [USERNAME]"}],"type":"security_exception","reason":"action [cluster:admin/ingest/pipeline/put] is unauthorized for user [USERNAME]"},"status":403}

I tried several things, but for the life of can't get it to run without pipeline related permissions:

• we set pipeline: "" on the log input (also tried without that)
• we set pipeline: ""on global level (also tried without that)
• we set pipeline: ""on the elasticsearch output (also tried without that)
• and we also have setup.template.enabled: false and setup.ilm.enabled: false, additionally also setup.template.overwrite: false and setup.ilm.check_exists: false though I think those two shouldn't even be considered when setup.ilm.enabled and setup.template.enabled are both set to false

Though from what I understand in this issue, is that this is a known issue.

[fholzer]

I reverted to our previous configuration, but I noticed a big difference. I think when having certain(/any?) modules enabled, it will try to fiddle with pipelines. Our old (and now current) configuration is missing the modules section completely and filebeat no longer tries to query the existing pipelines.

[iorfix]

Hi @fholzer I just resolved with granting read_pipeline privileges (according to new documentation)

[dedemorton]

The info in this issue is quite old. The Beats security docs have been updated several times over the past 3 years. I am going to close this issue now. If there are additional problems with these docs, please open a new issue. Thanks!

[DanRoscigno]

I am getting quite old too @dedemorton :) Good to see your name pop up in my email.