Is there any way possible, or planned, to update only a part of the sg_config ?
We have a requirement to make a dynamic update to a single setting (for our custom authentication backend) and it’s architecturally inconvenient for the component responsible for that to know the full sg_config.yml. GET-MODIFY-PUT seems to be the only approach.
Related: is there an interface that could be used from within an auth backend module to update configuration (rather than calling our to invoke sgadmin)?
Thanks,
James
The closest thing is probably the REST API. At the moment we do not support changing the contents of sg_config with the REST API (due to security considerations). But there is a feature request lurking in our backlog already to support this. We do not get many requests for that particular feature, so I can’t give you an ETA at the moment. I’d like to learn more about the particular usecase if possible. You write:
" it’s architecturally inconvenient for the component responsible for that to know the full sg_config.yml"
Could you elaborate a bit what your particula use case is? If we understand it better, we might be able to push the feature up the priority list, or come up with a different solution.
As to your second question: There is no public API to modify the contents of the Search Guard index. The index contains sensitive information, and by making it officially accessible via an API we would open potential security leaks. Again, knowing a bit more about your use case would help to evaluate the feasibility of such an API.
Thanks!
···
On Tuesday, November 6, 2018 at 2:54:57 PM UTC+1, jbeckett@ft-services.com wrote:
Is there any way possible, or planned, to update only a part of the sg_config ?
We have a requirement to make a dynamic update to a single setting (for our custom authentication backend) and it’s architecturally inconvenient for the component responsible for that to know the full sg_config.yml. GET-MODIFY-PUT seems to be the only approach.
Related: is there an interface that could be used from within an auth backend module to update configuration (rather than calling our to invoke sgadmin)?
Thanks,
James
Our auth backend module uses JDBC and sometimes the connection string (in the sg_config authc section) needs changing to point to a different server; we have an existing mechanism to make such changes, but the microservice providing that won’t have access to the location where we keep the sg config (due to security considerations). Sounds like GET-MODIFY-PUT might be the way to go, although it also infringes on that model. Or I’ll write another communicating service cough script.
For the second, I was more thinking of a programmatic interface to sgadmin, so we don’t need to discover the location of the sgadmin program (and be subject to the plugin security policy trying to run it). Perhaps the SearchGuardAdmin class is accessible and its main() could be invoked with a constructed args list?
Thanks, that makes sense. It would also benefit users that, say, need to change their LDAP server without changing the complete config. We will release an update to the REST API soon which will allow you to change individual parts of the configuration (say, only the DLS settings for a particular role). But like I said, that does not include sg_config. I will add it to the backlog however, I guess providing this functionality makes sense now to me.
Regarding sgadmin: Sure, it is “just” a Java class with a main method, you should be able to invoke it from another class. Not nice, I know, but maybe doable for the moment. We are also thinking about providing an interface with different language bindings to the REST API which would make it easier to include SG in other projects.
On Maven/Sonatype you will find an sgadmin standalone download. It’s sgadmin and all required dependencies. The intent was to provide an sgadmin bundle that you can run from any machine. Maybe this is helpful when you want to invoc SearchGuardAdmin from another class.
···
On Wednesday, November 7, 2018 at 5:45:09 PM UTC+1, jbeckett@ft-services.com wrote:
Our auth backend module uses JDBC and sometimes the connection string (in the sg_config authc section) needs changing to point to a different server; we have an existing mechanism to make such changes, but the microservice providing that won’t have access to the location where we keep the sg config (due to security considerations). Sounds like GET-MODIFY-PUT might be the way to go, although it also infringes on that model. Or I’ll write another communicating service cough script.
For the second, I was more thinking of a programmatic interface to sgadmin, so we don’t need to discover the location of the sgadmin program (and be subject to the plugin security policy trying to run it). Perhaps the SearchGuardAdmin class is accessible and its main() could be invoked with a constructed args list?