Hi,
Other than going to the Kibana console and creating a role with a set of permissions manually, what other methods are best to carry out this type of request?
We need to be able to automate the process.
Thanks
Hi,
Other than going to the Kibana console and creating a role with a set of permissions manually, what other methods are best to carry out this type of request?
We need to be able to automate the process.
Thanks
PLUS ONE – I have also encountered this recently and would be interested in this functionality - Thanks
We usually do it via configuration files - in order to be able to restore all required permissions in case of he security index initialisation.
Thanks for your response. Yes, we also modify the YML files in opendistroelasticsearch to retain the settings.
Please let me clarify.
In Kibana (opendistro-kibana)
Security
Roles
logstash (reserved)
Logstash had MOST of what I needed however, I had to add cluster:monitor/main so I cloned into logstash-writer and added the right.
When I reran securityadmin.sh to fix another small issue - - my new logstatsh-writer disappeared.
Is there a YML I could add this to?
b/c I have yet to find it
thanks in advance
You can use a script (python for example) to pull the config from a json file (with the settings you want) and fire it at the api in opendistro (for the section you want to update).
Interesting concept - -I LOVE IT
Is there a particular JSON that I should look for - specifically where my addition of logstash-writer was placed (for formatting, placement etc)
Thanks in advance
As you have discovered, re-running the securityadmin.sh script re-initializes all of the security configuration files…and, thus, wipes out any/all security changes you’ve made via Kibana or via API calls. You could add your new user to the roles.yml and roles-mapping.yml files that are part of the security configuration. This would mean it would be re-created whenever you run the securityadmin.sh script (since the definition is part of the initialization files). But, you will still lose any/all security changes made via Kibana (or API calls) if you later re-run the securityadmin.sh script.
The other option is to never run the securityadmin.sh script (other than letting it run the first time) and do everything security-related via Kibana and/or API calls after that. I believe this is the “recommended” approach based on the following quote from the Users and roles section of the doc where is is presented in a highlighted box:
Unless you need to create new read-only or hidden users, we highly recommend using Kibana or the REST API to create new users, roles, and role mappings. The
.yml
files are for initial setup, not ongoing use.
It probably may depends on the you configuration management. In our case, with lees then 50 users it is easier to store all of them in the configuration files and in case of the restore all of them will be ready for the usage.
We probably can store users creation scripts via API in IAC as well but we should think about their passwords and with configs we store just password hashes.
The simplest way is to dump a config using the api and then adjust to your needs, you then load them back in with curl through the api.You can then keep all your config in a repo that you back up and keep building it up. We keep passwords in AWS SSM and the script pre-populates the password before it loads the configs back in.
Thank you ALL for your replies – these are REALLY good thoughts that extend my thinking and they are much appreciated. The API - - that is an interesting thought and I will speak to your API guru but for right now - we have VERY little in Kibana changes to manually do so it would be easiest to just go manual for the time being.
Thanks again for taking your time to comment and I appreciate them all
cwc