I am creating a user via curl and assigning a it a role which is defined in roles.yml. Is that a valid way of assigning roles? Do I have to create roles via curl also?
In my opinion roles on roles.yml is valid but is a bit painful because it doesn't let you scalate easily due the need of modify each roles.yml file.
In my opinion if you don't need really advanced roles and for easier management would be better use Kibana management UI.
If you need more advanced roles that goes beyond Kibana's security UI I would recommend to use the API.
Kibana Documentation: https://www.elastic.co/guide/en/kibana/current/xpack-security.html
I hope this helps.
That is valid, but I would question why you would choose to do that.
We recommend you use API for easy of maintenance, and only use files for the users + roles that absolutely have to work even when your cluster is red.
The why part is very simple. When you have an orchestration tool like Puppet, it is simpler to make modifications in multiple places/servers. Invoking a REST API will require me to have another server from which I make the REST call.
Mmmm You don't need a server to make a rest api call, you can do it from Kibana's Dev tools or tools like postman if you use windows in case you use linux its even easier with curl.
I absolutely understand what you are saying but probably you did not get what I am going for. When I am using a deployment tool like Puppet, I would define a role which gets applied to a server. So, let's say I have roles for all elastic components, viz. elasticsearch, Kibana, Filebeat, etc. Now, to execute the curl command, I have two options:
- manually execute the curl command from a machine (not acceptable)
- put the curl command as part of the deployment scripts: Let's say the curl command is part of elasticsearch setup. That will make the command execute on each elasticsearch node which does not make sense.
I never worked personally with puppet, but I find hard to believe that it doesn't allow you to to use different configurations or tasks after orchestate the deployment of a number of machines, even in elasticsearch the nodes are not allways contains the same configuration etc.. I think there must be a way to execute a script after that in only one machine or even in the orchestator server.
Why would you want to use an orchestation tool for something that needs to be done only in 1 place?. You only have to change it in one place.
If I were not to use a configuration management tool for it, how do you suggest that I should do it?
How would you automate that? The elasticsearch machines will be segregated by roles: master, indexer etc. How will you pick which machine to run the one-time script on?
When setting up an evironment there are often tasks that you need to perform once for a group of hosts so I would be surprised if Puppet (which I have never used) does not support this. That is however a question better suited for a Puppet forum.
Depending of your infraestructure I can think this methods:
In the same script have a list of node and a little function which check the health before pick one in order to make the rest call.
Just put the client nodes in front of a LB and point the script to the LB.
As always in elastic it depends, you also must be aware of your architecture, if you have client nodes just figure out a way to ensure that the REST call arrives to any of them with for example any of the provided methods above.
The only nodes which I wouldn't send requests are the master dedicated.
I hope this helps
Logically speaking, an Elasticsearch cluster is a thing to manage. It is made up of nodes that also need to be managed, but there are many things that you might want to manage as a "thing" in a cluster not per-node.
Roles are one such thing, but so are index templates, scripts and cluster settings.
Even if you put roles into a per-node file, you will eventually run into problems that cannot be solved by simply treating a cluster as a series of nodes. You will need to find a way to use puppet (or if necessary some other tool) to manage a cluster.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.