Built-in superuser role grants access to Kibana despite UI saying it does not?

I'm a bit confused and wondering if there is a UI bug, as well as perhaps clearer documentation.

On /app/management/security/roles/edit/superuser it says at the bottom:

This role does not grant access to Kibana

However in practice, a user with only the superuser role is in fact able to log in to Kibana and do anything they like.

Now it makes sense in my head that a role named 'superuser' should be able to do this, but the Kibana UI when viewing that built-in non-editable role seems to be misleading / outright wrong?

Also perhaps the superuser section on Built-in roles | Elasticsearch Guide [8.12] | Elastic should explicitly say that it is 'special' in some way and does grant all Kibana permissions (currently it only talks about all the indices that it grants access to).

Hi @sparrowt Perfect question and yes a bit confusing ... perhaps the documents should be clearer

What this is saying is that you can not use the elastic user in the kibana.yml to connect the kibana application to elasticsearch application that will not work.

in the kibana.yml you will notice the default is the proper

#elasticsearch.username: "kibana_system"
#elasticsearch.password: "pass"

so kibana_system is the correct user unlike in the past the elastic super user was used ... which was not as secure...

If you try to use the following it will fail.

elasticsearch.username: "elastic"

Hope that helps

I see (maybe?) though is that really the intention of the role editor UI? I'm not configuring any native users or doing anything to do with the elastic<=>kibana connection, just using Elastic Cloud and looking at roles to be applied to SSO users.

I am simply viewing the role named superuser and looking at what it says under the Kibana heading, which for other roles shows which spaces & actions are granted, or in the case of something like watcher_user it says the same thing: "This role does not grant access to Kibana" (which makes sense and is true in that case).

Whereas for /app/management/security/roles/edit/superuser that same bit of UI says something that is just not true afaics - presumably the superuser role has special treatment in the code somewhere such that it nevertheless grants 'all' on all spaces?

I explained with the users are for above...

But now I see (sorry) you are talking about roles.... sorry

You are looking at:

Yup that is confusing BUT if you simply run this in Kibana - Dev Tools

Login as the elastic user you will see this

GET _security/role/superuser
GET /_security/_authenticate
GET /_security/user/_privileges

You will get this.. and this shows that

# GET _security/role/superuser 200 OK
{
  "superuser": {
    "cluster": [
      "all"
    ],
    "indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "all"
        ],
        "allow_restricted_indices": false
      },
      {
        "names": [
          "*"
        ],
        "privileges": [
          "monitor",
          "read",
          "view_index_metadata",
          "read_cross_cluster"
        ],
        "allow_restricted_indices": true
      }
    ],
    "applications": [ << All Kibana Here
      {
        "application": "*", << All Kibana Here
        "privileges": [
          "*" << All Kibana Here
        ],
        "resources": [
          "*" << All Kibana Here
        ]
      }
    ],
    "run_as": [
      "*"
    ],
    "metadata": {
      "_reserved": true
    },
    "transient_metadata": {},
    "remote_indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "all"
        ],
        "allow_restricted_indices": false,
        "clusters": [
          "*"
        ]
      },
      {
        "names": [
          "*"
        ],
        "privileges": [
          "monitor",
          "read",
          "view_index_metadata",
          "read_cross_cluster"
        ],
        "allow_restricted_indices": true,
        "clusters": [
          "*"
        ]
      }
    ]
  }
}
# GET /_security/_authenticate 200 OK
{
  "username": "elastic",
  "roles": [
    "superuser"
  ],
  "full_name": null,
  "email": null,
  "metadata": {},
  "enabled": true,
  "authentication_realm": {
    "name": "found",
    "type": "file",
    "domain": "cloud-file"
  },
  "lookup_realm": {
    "name": "found",
    "type": "file",
    "domain": "cloud-file"
  },
  "authentication_type": "realm"
}
# GET /_security/user/_privileges 200 OK
{
  "cluster": [
    "all"
  ],
  "global": [],
  "indices": [
    {
      "names": [
        "*"
      ],
      "privileges": [
        "all"
      ],
      "allow_restricted_indices": false
    },
    {
      "names": [
        "*"
      ],
      "privileges": [
        "monitor",
        "read",
        "read_cross_cluster",
        "view_index_metadata"
      ],
      "allow_restricted_indices": true
    }
  ],
  "applications": [
    {
      "application": "*",
      "privileges": [
        "*"
      ],
      "resources": [
        "*"
      ]
    }
  ],
  "run_as": [
    "*"
  ],
  "remote_indices": [
    {
      "names": [
        "*"
      ],
      "privileges": [
        "all"
      ],
      "allow_restricted_indices": false,
      "clusters": [
        "*"
      ]
    },
    {
      "names": [
        "*"
      ],
      "privileges": [
        "monitor",
        "read",
        "read_cross_cluster",
        "view_index_metadata"
      ],
      "allow_restricted_indices": true,
      "clusters": [
        "*"
      ]
    }
  ]
}

So yeah why the UI says that... huh... not sure if I get a chance to find out I will let you know...

That said I would just move forward...

You can test

Create a users mytest assign it role superuser you will see you have all access to kibana.

I asked internally lets see if I get answer... you got me curious :wink:

Asked internal...

It’s a known, and unfortunately longstanding issue: superuser role's Kibana privileges are inaccurate · Issue #106561 · elastic/kibana · GitHub

Sorry yes I should've included a screenshot to start with.

Aha ok thanks - at least it is known.