Kibana role privileges in upgrade 7.15.2 to 7.17.10

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

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.

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

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?

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