Designing a security model for your own systems is very much as case-by-case situation. You have to consider questions such as:
- Are you authenticating users or other systems?
- Is it OK for 2 users (or systems) to share a single account?
- Should administrators have high-privilege access under their own personal account, or use a special admin account?
- Do you want to hook into a central password management system, or have local passwords?
- Do you want to use passwords at all, or just use (SSL) certificates?
If doesn't sound like you're in a place where you need to worry about those things too much, but I want to give that disclaimer up front because my advice below is going to be specifically answering to the questions in your post, and is not general advice for X-Pack security.
That's an appropriate first step. If you have multiple logstash instances, or multiple pipelines, then you might consider having several logstash users for writing into different indices, but it doesn't sound like that's your scenario.
Depending on what you are using Kibana for, you might consider having individual logins for Kibana. The most common setup is that everyone who logs into Kibana has their own personal login with individual privileges.
Elasticsearch doesn't need its own user. The users you are creating (I assume you're using the Kibana management UI) are users inside Elasticsearch and are controlling who have access to which indices inside Elasticsearch.
You only need users when you're pulling data in or out of Elasticsearch.
But if you're using logstash, there's a reasonable chance you'll want something like curator at some point in order to clear up old data. If you do that, then you'll want to create a user for that.
Our recommendation is that you use the
elastic user for as little as possible. If has superuser privileges and can do a lot of damage to your cluster if you do the wrong thing. You definitely don't want to use it in a logstash pipeline, but even for user admin, I would encourage you to think about having another user with the
manage_security privilege. It's probably not particularly important for your current setup, but in the longer term you ought to move away from using a
superuser for things that don't need it.