Cluster privileges manage_security does give user right to alle CRUD operations on a role

This issue is happens on Elasticsearch and Kibana version 8.15.0 (upgraded many times).

A role has been created by the Elastic user. According to Kibana 8.15.0 documentation the cluster security privileges manage_security should give access to all CRUD operations on roles.

manage_security All security-related operations such as CRUD operations on users and roles and cache clearing.

I have a role A created by the elasic user and an other role B assigned to some users. I want the users with role B to be able to view and edit role A. Following the Kibana documentation I assign the manage_security privilege to role B.

However, the users in role B can not see and edit role A in Kibana. They can also only see a few users in Kibana, not all users. I have also tried to assign the all privilege to users in role B, but the result is the same.

Any help og hint?

Best regard
Flemming

Elasticsearch is designed to work the way the docs suggest, not the that you are experiencing in Kibana.
I think we need to drill down on what you are actually seeing, and why it doesn't match what would be expected.

Can you provide the role definition for "role B" ? It sounds like you've done the right thing, but it would be helpful to see the definition exactly.
Go to the "Console" in Kibana "Dev Tools" and run

GET /_security/role/role-b

(replacing "role-b" with the real role name) and paste the response here.

Let's try and narrow the problem down.
Can you get one of those users to login to Kibana and go to the Console, and run

GET /_security/role/role-a

(replacing "role-a" with the real role name)

Does that work? If not what does the error message say?

Likewise, what if they call

GET /_security/user/

Do they see the same set of users as when the elastic user calls that API?
If not, is there anything special about the users that are missing?
Pick a username that is present for elastic but missing for the users in role-b, try

GET /_security/user/the_username

Does that have an error message?

Hello @TimV ;

Thanks for answering this issue swift.

Here are the answers to your questions:

Role A =STAR_Institution
Role B=dkeessi_developer

  1. As user elastic i Kibana dev tooles
GET /_security/role/dkeessi_developer

{
  "dkeessi_developer": {
    "cluster": [
      "all"
    ],
    "indices": [
      {
        "names": [
          "apm-*",
          "auditbeat-*",
          "packetbeat-*",
          "journalbeat-*",
          "winlogbeat-*",
          "metricbeat-*",
          "filebeat-*",
          "heartbeat-*",
          "apmonitoring",
          "gwmessages-*",
          "filewinlogbeat",
          "shrink-*"
        ],
        "privileges": [
          "read",
          "view_index_metadata",
          "monitor",
          "all"
        ],
        "field_security": {
          "grant": [
            "*"
          ],
          "except": []
        },
        "allow_restricted_indices": false
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_discover.all",
          "feature_visualize.all",
          "feature_dashboard.all",
          "feature_dev_tools.all",
          "feature_canvas.all",
          "feature_logs.read",
          "feature_infrastructure.read",
          "feature_apm.read",
          "feature_uptime.read",
          "feature_observabilityCases.read",
          "feature_actions.all",
          "feature_stackAlerts.all",
          "feature_savedObjectsTagging.all",
          "feature_siem.minimal_read",
          "feature_siem.cases_read",
          "feature_securitySolutionCases.read"
        ],
        "resources": [
          "space:default"
        ]
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
  }
}
  1. As a user with Role B run

GET /_security/role/STAR_Institution

Response in Kibana dev-tools is 404 not found

3, As a user which should be have the dkeessi_developer role run

GET /_security/user/

{
"[nn.mm@xxx.com](mailto:nn.mm@xxx.com)": {
"username": "[nn.mm@xxx.com](mailto:nn.mm@xxx.com)",
"roles": [
"brugerrejser_writer",
"monitoring_user",
"superuser",
"editor"
],
"full_name": "Nn",
"email": "Mn",
"metadata": {},
"enabled": true
},
"[ooo@zzz.dk](mailto:ooo@zzz.dk)": {
"username": "[ooo@zzz.dk](mailto:ooo@zzz.dk)",
"roles": [
"superuser",
"editor",
"brugerrejser_writer"
],
"full_name": "OOO",
"email": "OOO",
"metadata": {},
"enabled": true
}
}

This looks wrong to me.

However, if elastic run the query

GET /_security/user/nn.mm@xxx.com

the answer looks as expected

"nn.mm@xxx.com": {
    "username": "nn.mm@xxx.com",
    "roles": [
      "dkeessi_developer",
      "dkeessi_servicedesk",
      "monitoring_user",
      "watcher_user",
      "superuser",
      "kibana_admin"
    ],
    "full_name": "Nn Mm",
    "email": "nn.mm@xxx.com",
    "metadata": {},
    "enabled": true
  }
}

What's the response if you run it as the elastic user?

Is it possible that this role is defined in a file or via a plugin rather than via the API. Only API-managed roles are returned via the API.

What looks wrong?

Something has inserted mailto links into the JSON, but I assume that was due to the way it was copied-and-pasted rather than being in the original output.
Other than that it looks good to me, but you know your data better than I will.

I assume these are not actually the same user, and you've just redacted the usernames in a way that makes them look like the same user.

If they are the same user and the API is returning different lists of roles at different times then that's something we need to explain.

Hello @TimV

Thanks for you help.

I resolved the problem by adding a new role which only has the manage_security privileges.

The next problem was we are working remotely, and my colleague which tested his privileges, did the tests on an other ELK cluster, which explains the responses he got.

That what happen - I happy we did not have a real issue in the Elastic cluster. I'll close this issue