# Cluster privileges manage\_security does give user right to alle CRUD operations on a role **URL:** \ **Category:** Elasticsearch\ **Created:** [August 20, 2024, 11:57am UTC](https://discuss.elastic.co/t/cluster-privileges-manage-security-does-give-user-right-to-alle-crud-operations-on-a-role/365196 "2024-08-20T11:57:07Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\ **Post date:** [August 20, 2024, 11:57am UTC](https://discuss.elastic.co/t/cluster-privileges-manage-security-does-give-user-right-to-alle-crud-operations-on-a-role/365196/1 "2024-08-20T11:57:07Z")
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 ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [August 21, 2024, 2:20am UTC](https://discuss.elastic.co/t/cluster-privileges-manage-security-does-give-user-right-to-alle-crud-operations-on-a-role/365196/2 "2024-08-21T02:20:46Z")
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 ```auto GET /_security/role/role-b ``` _(replacing "role-b" with the real role name)_ and paste the response here. > [@fgjensen](#): > > the users in role B can not see and edit role A in Kibana 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 ```auto 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 ```auto 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 ```auto GET /_security/user/the_username ``` Does that have an error message? ---
**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\ **Post date:** [August 21, 2024, 3:39pm UTC](https://discuss.elastic.co/t/cluster-privileges-manage-security-does-give-user-right-to-alle-crud-operations-on-a-role/365196/3 "2024-08-21T15:39:34Z")
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 ```auto 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 ```auto 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 ```auto "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 } } ``` ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [August 21, 2024, 11:28pm UTC](https://discuss.elastic.co/t/cluster-privileges-manage-security-does-give-user-right-to-alle-crud-operations-on-a-role/365196/4 "2024-08-21T23:28:55Z")
> [@fgjensen](#): > > 1. As a user with Role B run > > `GET /_security/role/STAR_Institution` > > Response in Kibana dev-tools is 404 not found 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. > [@fgjensen](#): > > This looks wrong to me. 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. > [@fgjensen](#): > > ```auto > "username": "[nn.mm@xxx.com](mailto:nn.mm@xxx.com)", > "roles": [ > "brugerrejser_writer", > "monitoring_user", > "superuser", > "editor" > ], > > ``` > [@fgjensen](#): > > ```auto > "username": "nn.mm@xxx.com", > "roles": [ > "dkeessi_developer", > "dkeessi_servicedesk", > "monitoring_user", > "watcher_user", > "superuser", > "kibana_admin" > ], > > ``` 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. ---
**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\ **Post date:** [August 22, 2024, 9:07am UTC](https://discuss.elastic.co/t/cluster-privileges-manage-security-does-give-user-right-to-alle-crud-operations-on-a-role/365196/5 "2024-08-22T09:07:17Z")
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