Updating the existing security configuration using the REST API

Security
,
1

In the “Update configuration” section in the API documentation it is specified that " This operation can easily break your existing configuration, so we recommend using securityadmin.sh instead, which is far safer".

Furthermore, in order to use this API we have to set “plugins.security.unsupported.restapi.allow_securityconfig_modification” to true in the opensearch.yml config. This implies that it is an unsupported REST API.

Can we get more information about what makes this API “unsupported” and what makes it fundamentally more dangerous than running the securityadmin.sh script (that can be quite fiddly and could itself break a cluster if used improperly) ?

Also, is there any plan to officially support it in the near future? There are use cases where using the API is more straightforward than running the script (eg: OpenSearch cluster running in kubernetes that is managed by an operator).

I’ve seen other people requesting this as a feature (eg: [BUG] securityadmin.sh -backup gives ERR: Seems audit from cluster is not in legacy format: java.io.IOException: A version of 1 · Issue #1876 · opensearch-project/security · GitHub) so I think at least officially supporting this API would be welcomed by the community.

Cheers,

Dan

1 Like
2

@dancristiancecoi As per OpenSearch documentation, the “plugins.security.unsupported.restapi.allow_securityconfig_modification” option regards only PUT and PATCH APIs.

It is recommended to use securtiyadmin.sh to modify the security plugin configuration.

Could you describe a scenario where securityadmin.sh could brake the cluster in your opinion?

3

Hey @pablo . Thanks for your reply!

I did not have specific examples for securityadmin.sh breaking the cluster. Just meant that if you apply a faulty security config with this script it probably has the potential for breaking it (though I know the script does some validation).

Also to clarify, I am not advocating for replacing the script with the REST API but I am asking for more specifics about what makes this API particularly dangerous to use compared to the script (and if this can be worked on and improved in the future releases). Is this the lack of validation of the config provided and its structure or is this something entirely different?

Extra documentation on this API would help a lot as it might allow developers to leverage it if they are aware of the specific risks and can minimize them.