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
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
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
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
- 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.