**Kibana version:** 8.0+
**Elasticsearch version:** aligned with Kibana
**…Describe the bug:**
On versions < 8.0, `.reporting*` indices could be deleted at least by the `superuser` or anyone who had `reporting_user` permissions.
On 8.0+, due to the fact `.reporting*` indices are considered system indices, even a `superuser` do not have the permission to delete them (as `superuser` doesn't have the permission to delete restricted indices starting 8.0).
**Steps to reproduce:**
1. Create report
2. Try to delete any `.reporting-*` index
**Expected behavior:**
A user should have the permission to delete reports and/or clean up old reports without having to use workarounds.
The current workaround is to create a dedicated role and a user assigned to it which grants:
```
{
"names" : [
".reporting*"
],
"privileges" : [
"monitor",
"read",
"view_index_metadata",
"read_cross_cluster",
"delete_index"
],
"allow_restricted_indices" : true
}
```
The problem occurs also when granting both `reporting_user` and `superuser` permissions.
```
{
"error" : {
"root_cause" : [
{
"type" : "security_exception",
"reason" : "action [indices:admin/delete] is unauthorized for user [lucalucaluca] with roles [reporting_user,superuser] on indices [.reporting-2022-03-13], this action is granted by the index privileges [delete_index,manage,all]"
}
],
"type" : "security_exception",
"reason" : "action [indices:admin/delete] is unauthorized for user [lucalucaluca] with roles [reporting_user,superuser] on indices [.reporting-2022-03-13], this action is granted by the index privileges [delete_index,manage,all]"
},
"status" : 403
}
```
The same problem occurs when using the new Kibana permissions.
Even granting the following to a given user, still blocks the removal of `.reporting*` indices.
```
{
"reporting_my" : {
"cluster" : [
"all"
],
"indices" : [
{
"names" : [
"kibana_sample_data_logs"
],
"privileges" : [
"all"
],
"field_security" : {
"grant" : [
"*"
],
"except" : [ ]
},
"allow_restricted_indices" : false
}
],
"applications" : [
{
"application" : "kibana-.kibana",
"privileges" : [
"feature_discover.minimal_all",
"feature_discover.url_create",
"feature_discover.store_search_session",
"feature_discover.generate_report",
"feature_dashboard.minimal_all",
"feature_dashboard.url_create",
"feature_dashboard.store_search_session",
"feature_dashboard.generate_report",
"feature_dashboard.download_csv_report"
],
"resources" : [
"*"
]
}
],
"run_as" : [ ],
"metadata" : { },
"transient_metadata" : {
"enabled" : true
}
}
}
```
**Any additional context:**
As `.reporting*` documents contains both the job/task definition and the "result" of the report, maybe we could decouple them into 2 separate indices? Also the `.reporting` index could become a "workspace" index (like `.async-search` index) where we keep only the jobs to be done and store the generated reports in a separate index.
Or otherwise we should provide a dedicated API to manage reports `_reporting` at ES or Kibana level and allow to delete specific reports or whole groups of reports.
~I would consider it a bug as it is a regression on features of reporting~
> This as an effect of the breaking change made by ES security to no longer allow the superuser role to manage system indices by default.
**PLEASE BE AWARE** that it is possible to auto-delete old Reporting indices modifying the ILM Policy `kibana-reporting`, adding a Delete phase.
So, this problem affects only users who are interested in deleting a specific reporting index.