I have the following problem. In an environment already created, where I have reserved users created using the file internal_users.yml I also have created users from the ODFE-Kibana UI.
I have to add a new reserved user. The fact is that I add it to my file internal_users.yml and I execute the script to load that file:
Unfortunately, I believe the best solution is to not add new users to the internal_users.yml file after the initial deployment. That is true for all of the security configuration YAML files. The documentation hints at this by saying:
The best use of these YAML files is to configure reserved and hidden resources, such as the admin and kibanaserver users. You might find it easier to create other users, roles, mappings, action groups, and tenants using Kibana or the REST API.
In theory, you could probably dump all of the users to a file using the REST API before making any change and then reload them after making your change to the internal_users.yml file. But I don’t think passwords will be output and, therefore, you would have to reset passwords for all users (or for those for which you don’t know the original password) when you reload.
But, if you absolutely need another reserved user, you are stuck changing the internal_users.yml file…and dealing with the loss of the users you created via the Kibana UI.
Maybe an option would be to run the securityadmin.sh script with the -r parameter, in order to “download” the current users configuration, then add the new user accordingly and run the securityadmin.sh (without -r this time and with -f pointing to your new internal_users file).
Thanks @spapadop. I was able to confirm that this does dump out all of the users including those created via the Kibana UI and via the REST API…and includes password hashes as well. Nice. We’re managing everything via REST API at this point, so I haven’t tested the other half (re-importing the files back in).