-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Breaking change] Reporting: remove reporting_user role #92485
Comments
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
ping @elastic/kibana-app-services |
Thanks @tsullivan <3 |
Pinging @elastic/kibana-reporting-services (Team:Reporting Services) |
I'm going to remove the |
PR ready: #100427 |
Change description
The reporting_user role is a legacy solution for granting Reporting feature privilege. In 8.0, the role should no longer be automatically created, and users who have that role should not automatically be granted privilege to generate reports in Kibana. Applications will instead use sub-feature control checks to enable Reporting for privileged users.
In 7.x, the Upgrade Assistant can help identify users that are granted privilege to generate reports using the legacy solution, and guide the admin to giving each user the replacement for authorization.Which release will ship the breaking change?
8.0
Describe the change. How will it manifest to users?
In 7.x, Reporting will have a new config setting, proposed as
xpack.reporting.roles.enabled
(Boolean), to control how users are granted the privilege to generate reports. The default istrue
which continues the existing behavior by default throughout 7.x Atrue
setting indicates to use the 7.x method to check the user's roles for the built-in role name that allows Reporting. Afalse
setting indicates the code to use feature controls. In 7.x,true
orfalse
is allowed; in 8.0, the only allowed value will befalse
.How many users will be affected?
All user accounts that generate reports with security enabled in 7.x need to move off of the legacy solution.
How can we programmatically determine whether the cluster is affected by this breaking change?
If a user account is
elastic
or has thereporting_user
role, those accounts need to be granted feature control access (per application) if they want to remain able to generate reports.What can users do to address the change manually?
xpack.reporting.roles.enabled
tofalse
How could we make migration easier with the Upgrade Assistant?
Are there any edge cases?
Test Data
Use the Get Users API:
Sample output:
elastic
should be prompted to have new Reporting privileges as this username is granted reporting privilege by default in the legacy solutionreportron
should be prompted to have new Reporting privileges as they have thereporting_user
rolereporting_user
role from the system.Cross links
Describes how/why Reporting privileges should use Feature Controls: #19914
The text was updated successfully, but these errors were encountered: