Kibana role privileges in upgrade 7.15.2 to 7.17.10

Elastic Stack Kibana
1

Hi Team,

We have recently upgrade from 7.15.2 to 7.17.10 and it appears the privileges hierarchy has changed .

We used to use the following for a dashboard role to manage dashboard editing in kibana and this had runtime field editing in 7.15.2 but is appears in 7.17.10 it does not

{
    "cluster": [
      "monitor"
    ],
    "indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "read",
          "read_cross_cluster"
        ],
        "allow_restricted_indices": false
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_discover.all",
          "feature_visualize.all",
          "feature_dashboard.all",
          "feature_dev_tools.read",
          "feature_advancedSettings.read",
          "feature_indexPatterns.read",
          "feature_savedObjectsManagement.all",
          "feature_graph.all",
          "feature_apm.read",
          "feature_maps.all",
          "feature_canvas.all",
          "feature_infrastructure.read",
          "feature_logs.read",
          "feature_siem.read",
          "feature_uptime.read"
        ],
        "resources": [
          "*"
        ]
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
}

We cannot seem to find a feature to enable runtime field create/edit without turning "feature_indexPatterns.read" to "feature_indexPatterns.all" which enables index pattern editing also which we did not want to allow.

Would appreciate some advice if we are missing something in the role privileges

2

Dashboards and runtime fields are very different things that do not go hand-in-hand. On the other side, runtime fields do go hand-in-hand with index patterns. I think it may have been a bug in 7.15 that runtime field editing worked without the privilege to modify index patterns.

3

Yes that was my thought, but thanks for the follow up, as we could not find anything more granular we allowed the "feature_indexPatterns.all" just hoping it does not cause us a mess long term.
We will refactor as we move to version 8

4

Hi, I brought this idea up with the team in charge of data view management. They pointed out that runtime fields don't necessarily need to be saved in a data view, they could also be executed in a search request.

There was an ask to clarify: is the intention to only limit who can save runtime fields in a data view? Or is the intention to limit who can use runtime fields in search requests as well?

5

Hi, it was just to limit runtime in data view not for search requests

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.