Document privileges for ILM

[dedemorton]

I think it's a little odd that our security docs are so prescriptive wrt the specific roles and users that we want people to create. In the interest of getting this info into the docs quickly (with minimum rework), I'm following the current design and recommending that users create a separate role.

We need to revisit these docs and simplify them (in a later PR) so that we clearly describe what privileges are required to do specific things and then leave it up to users to decide which roles/users to create based on how they want to restrict users.

[dedemorton]

Closes #10421

[dedemorton]

I'll improve the docs further (in a separate PR) based on the decisions that come out of #10241

[dedemorton]

Note...after merging and backporting this PR, I'll add additional info for 7.0: I'll mention that ILM is on by default and tell users to assign the ilm role to the beats writer.

[andrewvc]

I think we need to rework these docs to explain that:

1. ILM is on by default ("if you plan" sounds like it was opted into).
2. That the additional privileges of manage_index_templates, manage_ilm, and manage are only required during the setup phase.

It seems that maybe we need to add a role here called {beatname_uc}_setup with only these roles, and tell people to add that role temporarily.

Would love feedback from @urso . Is the above all correct?

[dedemorton]

@andrewvc I will fix the confusion around ILM being on by default in 7.0. However, I think it would be better for you to add your thoughts to the discussion here: #10241.

Out of this discussion, I'd like to identify an authoritative list of the roles that we want users to either create (or use)...and I want that list to encompass all the features we offer.

[urso]

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.