Elasticsearch: Make reindex.remote.whitelist a dynamic setting?

[joshuar]

I'm not sure why the reindex.remote.whitelist setting needs to be in elasticsearch.yml only? It would be useful to make this setting dynamic, which can be changed via the cluster settings API. That would make it easy to do one-off exports of data between clusters and/or helpful in environments where IP addresses, ports or hostnames are themselves dynamic. Is there a reason this setting currently has to be applied only in elasticsearch.yml?

[elasticmachine]

Pinging @elastic/es-core-infra

[dakrone]

@joshuar if it were dynamic, a malicious user could dynamically add a host to reindex.remote.whitelist and then continually request that the original ES server try to contact whatever host was added, essentially turning ES into a server that makes http connections on behalf of the malicious user. I don't think this should be a dynamic setting.

[imotov]

@joshuar, as @dakrone already explained, security is still the main concerned here. Making this setting dynamic would amplify the impact of a compromised server. For the users, who have other methods of protecting access to elasticsearch, there is an easy workaround of essentially disabling this setting by using a wildcard for the local domain, local subnet mask or even just *:9200 to completely open it.

We have discussed this and decided not to make this setting dynamic at this moment, but we might revisit this to possibly make this a cluster-wide setting during zen discovery redesign.

[Hendler]

Perhaps this setting could be available only on index creation?

I noticed that index.sort.field can only be updated on a closed index or on create for performance and other operational concerns, but perhaps limiting to create only (or the elasticsearch.yaml) would be also secure - or even a reindex.remote.allow_dynamic_whitelist that is in the yaml?