[Security Solution] Add privileges to Kibana System role for management of internal indexes in support of Elastic Defend features#138993
Conversation
elasticsearchmachine
added
v9.3.0
needs:triage
paul-tavares
added
>enhancement
:Security/Authorization
elasticsearchmachine
removed
the
needs:triage
|
Pinging @elastic/es-security (Team:Security) |
|
Hi @paul-tavares, I've created a changelog YAML for you. |
|
|
||
| // Kibana Security Solution EDR workflows team | ||
| // Internal/private indexes used by Security Solution in support of features that target Elastic Defend. | ||
| RoleDescriptor.IndicesPrivileges.builder().indices(".endpoint-*").privileges("all").build(), |
There was a problem hiding this comment.
Would it be possible to define more explicit/granular privileges here? We generally prefer granting the minimum set of privileges even for internal indices, It keeps usage as explicit as possible and it allows us to track evolution over time.
There was a problem hiding this comment.
Sure. I'll push through a change soon here. Thanks for the review
There was a problem hiding this comment.
Ok. I updated to give it what I think is the minimal set.
| // Kibana Security Solution EDR workflows team | ||
| // Internal/private indexes used by Security Solution in support of features that target Elastic Defend. | ||
| RoleDescriptor.IndicesPrivileges.builder() | ||
| .indices(".endpoint-*") |
There was a problem hiding this comment.
I think this pattern could be more restrictive:
.endpoint-script-file-*
or even:
`".endpoint-script-file-meta", ".endpoint-script-file-data"`
if no additions are expected.
There was a problem hiding this comment.
Sure. I'll do some quick testing to ensure that it all works for us in Kibana if we use the explicit full index names as you suggested above and will adjust. Thanks for the feedback
There was a problem hiding this comment.
Ok I updated them to a more restrictive index pattern
| ) | ||
| .build(), | ||
|
|
||
| // Kibana Security Solution EDR workflows team |
There was a problem hiding this comment.
nit: can this be grouped with other edr workflows privileges? (for example: edr-workflow-insights-*)
There was a problem hiding this comment.
sure. I'll refactor it. Thanks for the feedback.
| }); | ||
|
|
||
| // Elastic Defend internal index for response actions results | ||
| // Kibana Security Solution EDR workflows team |
There was a problem hiding this comment.
Hey @jfreden - could you take another look here... I had to split up the tests and not attempt to run along with .logs-endpoint.action.responses- below - that set of indexes has more privileges than the scripts one I'm adding support for.
paul-tavares
deleted the
task/olm-14941-kibana-authz-to-endpoint-index
branch
|
Any idea how this will work with Fleet RBAC per space? For example, we are trying to get away from having a Kibana Admin or Kibana System role for our administrators because we need to separate having that deep of administrative privileges that can access any space design. We need admins in Space X that can manage Fleet, Agents, Defend different lly than Space Y. For example, SOC can read all of Space X and not make changes but Server admins can read/write Space X and not see a Space Y. Kibana System/Admin had been seemingly a requirement for some of these deeper setups and configurations when I would rather have the exact needed privileges per space, so having them documented on how to achieve this without Kibana Admin/System would be nice. I just want to make sure this future feature can be segregated like most other features. If none of this applies, feel free to tell me to buzz off! :) |
🤣 Hey @nicpenning 👋 . Re: Space Awareness The current implementation of space awareness in Fleet (and in Security Solution Elastic Defend workflows) should already support the use case you detailed:
The need for an internal "user" (Kibana System) remains necessary due to the fact that Fleet's space awareness allows Policies to be shared across spaces, and thus when compiling data for delivery to the Agent/Host there is a need to access all spaces. The Spaces implementation for Elastic Defend in Kibana follows the same model as Fleet, thus internally, we use the Kibana System user to ensure that data from multiple spaces is compiled for the agent that are running Elastic Defend. Hope I understood your concern correctly and that this response helps clarify the usage/need. |
|
Perfect, that makes sense to me, thank you for taking the time to explain this to me! Have a great day! |
|
@paul-tavares Can you update the Kibana System Privileges spreadsheet to reflect these changes? |
|
@jeramysoucy - done. I added a new row entry to the worksheet |
5 participants
Description
Changes the Kibana System role with:
.endpoint-*index pattern.endpoint-script-file-metaand.endpoint-script-file-data