[Reporting] use new application privileges model for reporting’s security perms

[alexfrancoeur]

What we have

Reporting currently utilizes a "higher-order handler" function to determine if the user (who initiated the request) has access to reporting. This is both a check on their licensing level, security setup, and if a configured (or not) reporting_user role is in their roles definition. This system works for what we have today but is lacking in a few areas:

• We're not able to take advantage of API keys internally.
• Having a hard-coded, or pre-configured, role makes troubleshooting issues tougher.
• Reporting jobs are async, and since we can't utilize API keys, authorization for reports are short lived -- effectively a blocker for scheduled reports.
• Users, overall, will benefit from having a consolidated place to manage their teams permission models -- easing the cognitive burden on administrators.

Why do this?

For reporting to function as it is today, we don't actually need to do this. Scheduled reports, however, does require longer lived credentials which our current model doesn't support. In reporting today, we memorize certain headers from the initial job-creation request, and when our headless browser starts we "inject" these same headers on all network requests in order to mimic being the actual user. This is a doable workflow for ad-hoc reports since the user's authorization tokens last long enough to ensure the reports work. However, since scheduled reports will likely outlive authorization tokens, reporting will need a more flexible permissions model in order to run reports on a users behalf. This new permissions model should get us this "for free" as far as my understanding goes.

High-level work needing to be done

• Remove the conditional configuration check on the authorized_user_pre_routing module.
• Introduce an (optional?) dependency on the roles/perms plugin if needed. Need to verify what we need to do exactly in our consumption of the security plugin.
• Pass the request over to this plugin to validate if the user has permission to do what they need to.
• Update all relevant tests, integration tests, our documentation on this change.
• Update our documentation to use this new workflow over the existing configuration based approach.

Potential Downsides and caveats

Given the larger change our users will face with this, there might arise some issues we should be aware of.

• Confusion on why something isn't working when it did in a prior version.
• Slightly more complex setup, as we won't have a one-size permission model.
• Perhaps more context needed in SDH and other issues to determine why something isn't working.
• Complexity in our plugin to determine if a request can run (do they have the right licensing? Do they have security turned on and is the user logged in? Does the logged-in user have the right permissions to do what they want to do?). This also makes testing a bit more complicated to setup as well.
• Possibly requires a larger body of documentation to setup properly.

Open Questions

• This is a medium sized body of work that requires some care in implementation. Given the current model is to use a configured reporting_user role, do we want to try and use both systems to mitigate a breaking change?
• If we are to do both, then we'll need to decide "which one wins" in cases where both are defined. My assumption is to use the security plugin if available, over the configuration-based approach. Care must be used on this to determine if a user has actually setup reporting, or if the supplied roles are simply defaults.
• We also need to determine the intersection of pages to reports as well, so we can illustrate to our users how to setup reporting permissions for success. For example, if a user doesn't have access to Dashboards, they won't be able to generate a PDF of them regardless of what their permission level is.
• We'll also need to know, prior to development, how we want to setup these permissions. Are they a sub-feature of the pages users can access? Or do we declare these permissions as standalone features and rely on our users to know how to set them up properly for success?
• In early designs of scheduled reports, there's a workflow where users can start/generate reports from within the reporting page itself. When work begins on that, we'll need to be sure that we make use of the appropriate APIs to filter out portions of Kibana that the user doesn't have access to.
• What are the "default" states when no permissions are set? Allowed?

---

Original Issue:

Similar to the dashboard only mode configuration via the advanced settings view, users would like to configure roles that have access to reporting through the UI.

[epixa]

I think the solution here is to base reporting’s security perms off of the new application privileges model rather than continuing to rely on this role config. Then you’d get UI/API based control over this for free.

[elasticmachine]

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

[tsullivan]

I think the solution here is to base reporting’s security perms off of the new application privileges model rather than continuing to rely on this role config. Then you’d get UI/API based control over this for free.

This discussion has been trying to get off the ground. I'd say this is the issue to follow on that front, yes? #21689

[epixa]

@tsullivan that seems like an appropriate place to me, though in theory you might be able to do this with feature controls alone, which wouldn't require reports to be saved objects. @elastic/kibana-security might be able to clarify that.

I think reports being saved objects in the long run makes a lot of sense though.

[kobelb]

@tsullivan that seems like an appropriate place to me, though in theory you might be able to do this with feature controls alone, which wouldn't require reports to be saved objects.

This is entirely possible, and is likely the path we'd want to take if we want this in the immediate future. Changing Reporting to use saved-objects will get us a majority of the way where we want to go; however, it won't provide the ability to make reports user-specific, which Reporting currently implements.

Alerting will be taking a similar approach (but using saved-object internally) by creating an "Alerting Client" which will enforce the appropriate authorization rules, similar to what is automatically done by the SavedObjectsClient.

[tsullivan]

Open Questions
This is a medium sized body of work that requires some care in implementation. Given the current model is to use a configured reporting_user role, do we want to try and use both systems to mitigate a breaking change?

We should support both privilege models, and allow the user which model to choose (or both) using a config setting in kibana.yml. The default model will be the current one, where the roles.allow config is checked against the user's roles. That model will be deprecated with warning logs for the rest of 7.x. In 8.0, only the Feature Controls model will be supported. In 8.0, the roles.allow setting will be invalid as well.

If we are to do both, then we'll need to decide "which one wins" in cases where both are defined. My assumption is to use the security plugin if available, over the configuration-based approach. Care must be used on this to determine if a user has actually setup reporting, or if the supplied roles are simply defaults.

This should be resolved from my previous comment. The admin will have to opt-in to the new privilege model in 7.x, or be forced to use it when upgrading to 8.0. That makes it a safe and non-breaking choice of which model to use for the admin. For the plugin code, it makes the choice of privilege model explicit.

We also need to determine the intersection of pages to reports as well, so we can illustrate to our users how to setup reporting permissions for success. For example, if a user doesn't have access to Dashboards, they won't be able to generate a PDF of them regardless of what their permission level is.

We can make it so that the user doesn't need the all privilege for any given app to feature Reporting. The top-level privileges are all and read and we will define granular, sub-feature privileges which are taken from our KibanaFeatureConfig object.

We'll also need to know, prior to development, how we want to setup these permissions. Are they a sub-feature of the pages users can access? Or do we declare these permissions as standalone features and rely on our users to know how to set them up properly for success?

Sub-feature.

In early designs of scheduled reports, there's a workflow where users can start/generate reports from within the reporting page itself. When work begins on that, we'll need to be sure that we make use of the appropriate APIs to filter out portions of Kibana that the user doesn't have access to.
What are the "default" states when no permissions are set? Allowed?

The Reporting management page could have a 3rd checkpoint, in addition to the checks in the app UIs, and the check in the Generate Export API route handler.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[tsullivan]

The progress on this issue so far has been to create an example plugin for Reporting. Step 2 of the example plugin will be to instrument the privileges model around the example integration.

That will help with App Developers to understand how to instrument privileges model in the various places where Reporting is integrated (Discover, Visualize, Dashboard, Canvas)

[tsullivan]

Issue to track this as a breaking change, and use the Upgrade Assistant to surface user accounts that need migration: #92485

[tsullivan]

I've started work on this, and found a bit of groundwork that will need to happen: #94995

[tsullivan]

WIP PR #94966