7.8.0-42
Could an option be added that when enabled it allows for Searchguard REST API to return the password hash for an internal user? We are using Puppet to automate SearchGuard configuration and having the hash returned blank makes automating it a lot harder. Currently the two options are to either setting the hash temporarily and then disabling, or setting it to outright ignore the password hash. (side effect of using a desired state automation tool)
We used to have this in the feature queue. But we removed it due to security concerns. Why don’t you use sgadmin.sh to automate the setup?
Desired state config vs task based config automation. We don’t use it to create a new config, we use it to maintain and update the config automatically on an existing SearchGuard. We have 200+ roles mapped to various back end roles via oauth, for me the SearchGuard configuration files total many thousands of lines long and is generated by Puppet from various arrays and other external resources.
Puppet runs every 30 minutes, calls the API, and will change/correct anything that is not configured properly. If desired config matches actual config then no change is applied. Add a new group in some other project and it will automatically generate the proper SearchGuard config and apply it. Change a password in the password management system and it updates all associated services and applies it to SearchGuard.
To use sgadmin.sh would require generating a properly formatted config file, then calling sgadmin.sh to import it on every puppet run overwriting the previous config. We have done this previously but the REST API implementation is far better.
Ok, but why do you want to get the password hash for an internal user? To check if it matches the user password on another system? And update the password if it doesn’t match?
Is the main reason to make the config verification easier? As far as I understand, you store the internal users configs, and Puppet verifies them periodically comparing with the configs fetched from SG API.
Task based automation does not care what the existing password is; kick off a task and it will forcibly change the password hash. Desired state automation (Puppet) needs to know both the current state (current hash) and the desired state (desired hash) and will change it if it differs. Desired state is useful for password changes but also useful for managing large systems as defining desired state for large systems is easier then defining/chaining all the individual tasks required to reach the desired state.
Correct. The entire SearchGuard config is generated from code stored somewhere else. It only exists as resource statements until the point it calls the REST API. Puppet then runs every 30 minutes and makes sure the config has not deviated; corrects config rot, new additions, any removals that are necessary, and also changes to existing config such as changing passwords.
I add this to the feature queue. The ETA is either next release or the release after the next release. I’ll update you.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.