-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Description
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 is true which continues the existing behavior by default throughout 7.x A true setting indicates to use the 7.x method to check the user's roles for the built-in role name that allows Reporting. A false setting indicates the code to use feature controls. In 7.x, true or false is allowed; in 8.0, the only allowed value will be false.
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 the reporting_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?
- Change
xpack.reporting.roles.enabledtofalse - In Stack Management > Users / Roles, edit each user or role that should have privilege to generate reports, and enable the feature controls for them.
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": { "email": null, "enabled": true, "full_name": null, "metadata": { "_reserved": true }, "roles": [ "superuser" ], "username": "elastic" },
"metricbeat_writer": { "email": null, "enabled": true, "full_name": "Internal Metricbeat User", "metadata": {}, "roles": [ "metricbeat_writer", "kibana_user", "ilm" ], "username": "metricbeat_writer" },
"remote_monitoring_user": { "email": null, "enabled": true, "full_name": null, "metadata": { "_reserved": true }, "roles": [ "remote_monitoring_collector", "remote_monitoring_agent" ], "username": "remote_monitoring_user" },
"reportron": { "email": "changeme@example.com", "enabled": true, "full_name": "Reportron", "metadata": {}, "roles": [ "reporting_user", "data_user" ], "username": "reportron" },
"test_user": { "email": "changeme@example.com", "enabled": true, "full_name": "Test T. User", "metadata": {}, "roles": [ "apm_user", "data_user" ], "username": "test_user" }
}
- User
elasticshould be prompted to have new Reporting privileges as this username is granted reporting privilege by default in the legacy solution - User
reportronshould be prompted to have new Reporting privileges as they have thereporting_userrole - The admin should be prompted to remove the
reporting_userrole from the system.
Cross links
Describes how/why Reporting privileges should use Feature Controls: #19914