Stack Management and Kibana Privileges

[kobelb]

Current stack management authorization model

An example of one of the traditional stack management applications is Monitoring. Monitoring relies upon the user being granted the monitoring_user role which gives them the following privileges:

• cluster privileges: cluster:monitor/main, cluster:monitor/xpack/info
• index privileges: .monitoring-* read and read_cross_cluster
• Kibana application privileges: reserved_monitoring

There are two interesting things to note about the traditional stack management authorization model:

1. The user must be assigned an additional role to kibana_user to get access to monitoring within Kibana
2. The primary authorization for Monitoring is enforced by Elasticsearch's cluster and index privileges. We're using the Kibana application privileges solely to determine whether the Monitoring app should be visible within the app selector.

Kibana privileges

With the introduction of feature controls in 7.2, we've added the ability for users to grant access to individual features within Kibana. At this time, users can't be granted access to stack management applications using feature controls. The "Stack Monitoring" application can be hidden using Spaces, but the user is instructed to continue to use the monitoring_user role to grant access.

Furthermore, I don't think that we should consider trying to change the Kibana Privileges to be used to grant access to the stack management applications, and instead should look for another solution which I've presented below.

When a user is assigned the kibana_user role or another custom role which grants them the all base privilege (which grants them all access to all features), I don't think this should be giving them access to these stack management applications. Ignoring the backwards compatibility issues, the stack management applications cross system boundaries, they aren't just Kibana features. They're features which are available within Kibana, but they're used to manage the stack itself.

Potential solution

Users want an easy way to grant access to one or many stack management applications. We've used reserved roles for this purpose historically, but they're not the most intuitive approach. Additionally, reserved roles lack the ability to adjust the level of granularity, it's generally an all or nothing approach. This is the limitation that we hit with the kibana_user reserved role, it gave you access to everything in Kibana, but we couldn't only grant the user access to a subset of features in Kibana.

What I propose is that we add a "sibling" to the Elasticsearch and Kibana privileges of the role, which can be used to grant access to the stack management applications.

We could either add a section for all stack management applications:

Or we can add a section per stack management application:

Regardless of the above decision, we'll have to adjust the internal implementation of Kibana RBAC to accommodate these stack management "siblings". There are a few technical approaches we can take, but I'd like to hold off on that discussion until after we come to agreement on the aforementioned UX.

[elasticmachine]

Pinging @elastic/kibana-security

[kobelb]

/cc @mattapperson @elastic/stack-monitoring

[chrisronline]

I'm assuming that when the user clicks on monitoring_user role definition, they'll see a screen where the Elasticsearch and Kibana sections are empty, and one of these other areas will be what will contain the relevant information? Or how will that look?

[kobelb]

I'm assuming that when the user clicks on monitoring_user role definition, they'll see a screen where the Elasticsearch and Kibana sections are empty, and one of these other areas will be what will contain the relevant information? Or how will that look?

Correct, the monitoring_user role definition would only grant them access to the monitoring application which would either be its own section, or within the "stack management" section. It'll be similar to the view that we display for the kibana_user reserved role, where they only have access to the Kibana application and we don't allow the user to edit it:

The monitoring_user role would give the user all monitoring privileges, and the user would have to create a custom role to grant more granular privileges.

[chrisronline]

Cool, that makes sense!

In terms of UI, I'd suggest the second one, as I'm fairly sure that's more aligned with how our documentation looks. AFAIK, we don't have a category of docs entitled Stack Management, but we do/will have docs talking about Monitoring and Fleet as separate entities.

[cachedout]

Or we can add a section per stack management application:

Is there a reason we couldn't do both? It would be nice, at least from a UX perspective, if a user could select all management applications or pick and choose if they wanted to be more selective.

[kobelb]

Is there a reason we couldn't do both? It would be nice, at least from a UX perspective, if a user could select all management applications or pick and choose if they wanted to be more selective.

If we want the ability to easily grant a user access to all stack monitoring "feature", I think it'd make more sense for us to have a single "stack management" section, and within this section allow used to easily choose all applications.

[mattapperson]

this looks spot on to our needs!

[jinmu03]

I vote for a single "stack management" section with subsections of each stack management applications such as Stack Monitoring and fleet.

[kobelb]

The more that I've thought about the single stack management section, the less that I've found myself liking it.

When a user is authorized to use Fleet, they're authorized to register beats which run on various servers and drastically alter the method in which they behave.

Where-as, when a user is authorized to use Stack Monitoring, they're authorized to monitor the health of Elasticsearch, Kibana, Logstash, Beats and APM.

Additionally, the other Elasticsearch, Beats and Logstash management applications, which we've sometimes referred to historically as stack management applications, require privileges to their specific topics:

All of these aforementioned examples have different "scopes" in regard to the actions we're authorizing the user to perform that I'm hesitant to think they should be unified.

[C0FFEEC0FFEE]

Due to the deprecation / after the removal of the kibana_dashboard_only_user role there will be no way to hide the "Stack Management" section of Kibana. This feature is needed before removing the kibana_dashboard_only_user role.

[legrego]

@C0FFEEC0FFEE you'll want to follow the progress of #35965. I am actively working on adding support for hiding "Stack Management" completely if the user is not authorized to see any of the management features inside. WIP PR is at #67791