[Reporting] Kibana Application Privileges for Reporting

[tsullivan]

Release note: added an option to have Reporting features controlled by Kibana application privileges instead of by the reporting_user role.

Depends on #96097
Closes #19914
Closes #76210

Before, any user with the reporting_user role could use any Reporting feature. This PR allows Reporting be turned on and off by Kibana application privileges. A new configuration setting for kibana.yml toggles Reporting access privilege control between using security roles (deprecated) and UI Feature Controls (new platform).

The new setting is xpack.reporting.roles.enabled. It allows the Kibana admins to migrate Reporting from the deprecated scheme to the Kibana Platform scheme. The default value is true. This enables the legacy behavior of using xpack.reporting.roles.allowed as Elasticsearch security roles which identify the user as being granted Reporting privilege everywhere in Kibana. When the value is true, a warning is logged at startup that users should be migrated from the deprecated scheme to the new platform scheme. The warning will continue to be logged until the user migration is done. When the value is false, Reporting does not register itself as an Elasticsearch feature. Instead, applications take over and register Reporting as a sub-privilege. Administrators will give Reporting feature privileges through the Roles UI the Stack Management Security app.

Screenshot of the changes that this PR makes to the Edit role > Kibana privileges screen:

When xpack.reporting.roles.enabled is false and users have been granted privilege using feature controls, the migration from Reporting's legacy scheme to the new platform is done.

In 8.0, the only allowed value will be false.

Changes to plugins: Reporting, Features and Canvas

1. A method had to be added to the FeaturesSetup contract to allow Reporting to update internal state that triggers Reporting to be included when privileges are registered for the OSS applications. This is featuresSetup.enableReportingUiCapabilities() It is meant to only be called by Reporting.

2. A method had to be added to the ReportingSetup contract to allow Reporting-enabled applications to check if Reporting is configured for the New Platform behavior. If so, the application should register Reporting subfeature privileges. This is reportingSetup.usesUiCapabilities. Canvas was updated to call this method it its setup() phase before registering itself as a Kibana feature.

The following diagram shows the behavioral connections between the affected plugins. The parts added in this PR are highlighted in green.

Checklist

Delete any items that are not applicable to this PR.

• Test API Keys
• Documentation was added for features that require explanation or tutorials
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[tsullivan]

@elasticmachine merge upstream

[tsullivan]

@elasticmachine merge upstream

[tsullivan]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 4e90797
• Storybooks Preview
• Documentation Changes

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
canvas	1085	1086	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
canvas	1.2MB	1.2MB	+1.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
reporting	81.4KB	84.3KB	+2.9KB

Unknown metric groups

API count

id	before	after	diff
features	199	200	+1
reporting	126	131	+5
total			+6

API count missing comments

id	before	after	diff
features	89	90	+1
reporting	125	130	+5
total			+6

History

• 💔 Build #121258 failed c5cc50e
• 💚 Build #121212 succeeded 2e732f2
• 💔 Build #121164 failed 1a03dac
• 💚 Build #121137 succeeded 34b72c5
• 💛 Build #120822 was flaky 0bf2761

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[spalger]

FYI, this backport to 7.x is going to go into 7.14, not 7.13, unless an backport is opened to the 7.13 branch.

node scripts/backport --pr 94966 --branch 7.13

[bhavyarm]

This didn't make 7.13 BCs because of the missing backport. Zoomed with @tsullivan and @LeeDr and this is what we get for setting the key in kibana.yml - xpack.reporting.roles.enabled: true

 [18:07:11.840] [fatal][root] ValidationError: [config validation of [xpack.reporting].roles.enabled]: definition for this key is missing
    at ObjectType.validate (/Users/bhavyarajumandya/Desktop/snapshot_7.13.0/kibana-7.13.0-SNAPSHOT-darwin-x86_64/node_modules/@kbn/config-schema/target/types/type.js:51:19)
    at ConfigService.validateAtPath (/Users/bhavyarajumandya/Desktop/snapshot_7.13.0/kibana-7.13.0-SNAPSHOT-darwin-x86_64/node_modules/@kbn/config/target/config_service.js:170:23)

Removing 7.13.0 label from this. Thanks!