# Indices vs cluster vs x-pack user privileges **URL:** \ **Category:** Elasticsearch\ **Created:** [May 14, 2017, 9:37pm UTC](https://discuss.elastic.co/t/indices-vs-cluster-vs-x-pack-user-privileges/85693 "2017-05-14T21:37:49Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![vijayramachandran](https://avatars.discourse-cdn.com/v4/letter/v/858c86/32.png) [@vijayramachandran](https://discuss.elastic.co/u/vijayramachandran)\ **Post date:** [May 14, 2017, 9:37pm UTC](https://discuss.elastic.co/t/indices-vs-cluster-vs-x-pack-user-privileges/85693/1 "2017-05-14T21:37:49Z")
Hello there! Can anyone explain me the privileges of x-pack users, indices privileges, and cluster privileges. x-pack users has got some privileges when they have created like superuser, monitoring\_user and goes on. (also I couldn't change their privileges if it's created as empty) indices has read, delete and it goes on. cluster has some privileges like delete, all, manage..... So, how do these all work? should I use it in a combination of these or something is required as prerequisite to have it first and the last two privileges can be assorted accordingly? Thanks ---
**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:** [May 16, 2017, 3:01am UTC](https://discuss.elastic.co/t/indices-vs-cluster-vs-x-pack-user-privileges/85693/2 "2017-05-16T03:01:32Z")
Hi @vijayramachandran I see you've got a lot of open threads, with questions on similar topics. I'm going to use this thread to post some general guidance on the X-Pack security model. Once you've gotten up to speed on that, we would appreciate it if you could go back and close off any questions that are no longer relevant, and then for any that are still a problem, provide an update on where you're stuck. # Realms The starting point for configuring X-Pack is realms. These control authentication (logging in) and the assignment of **roles** to users. I see you have questions that use the _file_ realm, the _ldap_ realm, and you've had pointers to the _native_ realm. For the sort of exploratory testing that you're doing now, I **_strongly_** recommend that you use the native realm. [https://www.elastic.co/guide/en/x-pack/current/native-realm.html](https://www.elastic.co/guide/en/x-pack/current/native-realm.html) The native realm has the following advantages: - It is consistent across the whole cluster - The API provides more validation - The Kibana UI uses the native realm - Assigning roles to users is straightforward Once you're familiar with the _native_ realm, and understand how all the other pieces fit together to produce a complete solution, then it's a good time to investigate the _ldap_ and _active\_directory_ realms, but configuring LDAP correctly is hard, and it will be much simpler if you can get comfortable with how X-Pack security works before you tackle that. # Roles In X-Pack, a **Role** is a _named collection of privileges_. It's a way of grouping a number of different privileges together, so that they can be assigned to a user. _Roles_ and _Privileges_ are therefore different things. **Users** are assigned **Roles** , and **Roles** are granted **Privileges**. You can define roles in files, but the recommended method is to store your roles inside Elasticsearch using either the _Roles API_ or the _Roles UI_ in Kibana. [https://www.elastic.co/guide/en/x-pack/current/defining-roles.html](https://www.elastic.co/guide/en/x-pack/current/defining-roles.html) The API and the UI operate on the same data - e.g. you can create a role in the UI and then view it through the API. File based roles are completely separate to that, and are not the recommended approach for what you are doing. # Privileges **Privileges** define what a user can actually do in Elasticsearch when X-Pack security is enabled. We document the available privileges at [https://www.elastic.co/guide/en/x-pack/current/security-privileges.html](https://www.elastic.co/guide/en/x-pack/current/security-privileges.html) **Cluster Privileges** give permission to do certain things that affect the whole cluster. **Index Privileges** give permission to take certain actions on specific indices. They are completely separate sets of privileges. For example: You _read_ data from an index, not the whole cluster, so `read` is an index privilege. If you want a user to read all the data in the cluster, then you can assign them a role that grants `read` to all indices in the cluster (by setting the index name to `*`) _but it is still an index privilege_ because it defines _which indices_ the user can read from. On the other hand `monitor` is a cluster privilege because it tells you about the health of the whole cluster, and `manage_security` is a cluster privilege because users and roles exist within the whole cluster, not within each index. You can't create a user within index "foo", you create users within the cluster. # Next Steps - I've linked to a few docs. Please go back and have another read of them, and ask specific questions if there are things in the docs that you don't understand. Those sorts of questions are always encouraged. - We have an X-Pack security on-demand training course that is _currently free_. It sounds like it would be of benefit to you, so I'd really encourage you to register while the discount still applies: [https://www.elastic.co/training/x-pack-security](https://www.elastic.co/training/x-pack-security) - Try to approach one problem at a time. Setup the _native_ realm. Create some users and roles via Kibana. Configure those roles exactly the way you need them. Then setup AD integration. There's a lot to take in if you try to jump straight to AD integration, but if you take it 1 step at a time, it's much simpler. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 13, 2017, 3:11am UTC](https://discuss.elastic.co/t/indices-vs-cluster-vs-x-pack-user-privileges/85693/3 "2017-06-13T03:11:03Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.