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).
@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?
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.
Hi @pablo What if I have plugins.security.config.dynamic.http.xff.internalProxies (added by ML commons)? Will this setting be overwritten by securityadmin.sh?
This isn’t added by ML commons. The ML plugin has no access to the security configuration.
securityadmin.sh is the recommended way to update the security plugin configuration
This pulls the current configuration from the security plugin index.
I would suggest to backup the current security plugin configuration before updating it, as running securityadmin.sh script overwrites the existing security plugin configuration.
The config.dynamic.http.xff.internalProxies is kept in /usr/share/opensearch/config/opensearch-security folder.
config:
dynamic:
# Set filtered_alias_mode to 'disallow' to forbid more than 2 filtered aliases per index
# Set filtered_alias_mode to 'warn' to allow more than 2 filtered aliases per index but warns about it (default)
# Set filtered_alias_mode to 'nowarn' to allow more than 2 filtered aliases per index silently
#filtered_alias_mode: warn
#do_not_fail_on_forbidden: false
#kibana:
# Kibana multitenancy
#multitenancy_enabled: true
#private_tenant_enabled: true
#default_tenant: ""
#server_username: kibanaserver
#index: '.kibana'
http:
anonymous_auth_enabled: false
xff:
enabled: false
internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
#internalProxies: '.*' # trust all internal proxies, regex pattern
#remoteIpHeader: 'x-forwarded-for'
###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
###### and here https://tools.ietf.org/html/rfc7239
###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve