Skip to content

[Breaking change] Reporting: remove reporting_user role #92485

@tsullivan

Description

@tsullivan

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?

  1. Change xpack.reporting.roles.enabled to false
  2. 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 elastic should be prompted to have new Reporting privileges as this username is granted reporting privilege by default in the legacy solution
  • User reportron should be prompted to have new Reporting privileges as they have the reporting_user role
  • The admin should be prompted to remove the reporting_user role from the system.

Cross links

Describes how/why Reporting privileges should use Feature Controls: #19914

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions