Extend the functionality of xpack.reporting.roles.allow option in kibana.yml

[Kvrepo]

Describe the feature:

As described in the documentation (https://www.elastic.co/guide/en/kibana/current/reporting-settings-kb.html#reporting-advanced-settings) with the xpack.reporting.roles.allow option the administrator can set which user roles can create reports.

I think it would be a nice to have feature to allow regexp like elements in this list. So instead of listing all the required roles here, one could use patterns to describe many.

Another nice to have feature would be to set a list of users who are not allowed to create reports.

Describe a specific use case for the feature:

Feature 1

In our case we have many different user roles, and we are probably going to create more in the future. Editing the kibana.yml each time that happens and restarting Kibana is a hassle.

Let's say we have the following roles: role1, role2, role3. (In our case each name follows a specific naming convention.)

Currently it looks like the following in the kibana.yml:

xpack.reporting.roles.allow: ["role1", "role2", "role3"]

If I want to create role4 and grant it the same privilege, now I have to edit the yml and restart Kibana. However if I would be able to use patterns, this could be avoided. I'm thinking about something like this:

xpack.reporting.roles.allow: ["^role.*"]

In this case a restart wouldn't be required, since it already applies to role4, too. In this case the users could also avoid calling for an administrator/developer to grant a user role this privilege each time they make one.

Feature 2

In our case we have more user roles which require this privilege than those which don't. So for our case it would be better to have a list of roles which are denied to use the reporting functionalities, instead of having a list of allowed roles.

Let's say we have role1, role2, role3, and we want role1 and role3 to be able to create reports, but not role2.

Now we have to set this up the following way:

xpack.reporting.roles.allow: ["role1", "role3"]

Instead of something like this:

xpack.reporting.roles.deny: ["role2"]

It would be really helpful in case of dealing with +20 roles.

[rayafratkina]

@kobelb can you comment if the RBAC will address this use case?

[kobelb]

@rayafratkina it's not part of the initial scope for our RBAC implementation, but once granular application privileges are in-place we should consider expanding this to allowing Reporting to be driven by these custom privileges, as opposed to the kibana.yml approach.

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[tsullivan]

@kobelb it's been awhile since last touching on this, but can you give an update? I'm curious to know what kind of work has to be done on the Reporting side. It's something we want to get to (after NP migration)

[kobelb]

@tsullivan, that is a great question...

The first decision that we'll want to make is whether or not it makes sense to treat Reporting as a top-level feature that is a sibling to all of the other top-level features:

Or whether it makes sense for us to treat Reporting as a sub-feature of the other top-level features, like Dashboards:

If we want Reporting to be a sub-feature, we'll have to wait on #35616 to be implemented.

After making the top-level feature vs sub-feature decision and assuming we want to implement this in a minor version, we can take advantage of #42470 so that we don't grant users access to Reporting that don't already have access to Reporting. This will allow users to begin to grant access to Reporting using Kibana Privileges.

We'll then want to modify the authorization which is done by the Reporting routes to first check to see whether the user is authorized based on Kibana Privileges, and if they aren't fall-back to using the existing authorization logic and log a warning that we're relying on a setting which is deprecated and will be removed in the next major version of Kibana.

[tsullivan]

I love the mockups! It helps really crystallize this future improvement.

I am fairly certain Reporting will be a sub-feature of apps, as Reporting team is positioning itself as a service for other apps to expand their functionality.

Your point about keeping existing logic, and logging it as deprecated, until the next major version gives my team a lot to think about on what we'll deliver in each minor release until.... 8.0? That seems so soon!

[tsullivan]

@kobelb another question, does this issue interdepend on #21689 ?

[kobelb]

@kobelb another question, does this issue interdepend on #21689 ?

Nope, it doesn't have to.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

In 7.14, Reporting access control will be driven by custom permissions: #94966