Change `action.destructive_requires_name` to a static module

[majormoses]

action.destructive_requires_name has been something that everyone should run in production for safety reasons and now that the default changed from false to true I think it should be a static module (probably in the next major release as it is a breaking change) so that you can protect against a lazy developer rescuing, updating settings, and making the request. It should be a setting that should be changed with a lot of thought and disruption (rolling restart) convincing them that a better solution is to simply have a query builder return a list of indices to delete and delete them in circumstances where you need regex expansion.

[elasticmachine]

Pinging @elastic/es-core-infra

[jpountz]

now that the default changed from false to true

It still seems to default to true?

[jasontedor]

Would you explain what "static module" means in this context, it is the word "module" that is throwing me off? Is the request here that this setting no longer be dynamic only?

[majormoses]

What I mean is that it can't be set via the api, it should only be able to set through cluster initialization or a rolling restart.

[majormoses]

I was attempting to use the terminology in the documentation here:

• https://www.elastic.co/guide/en/elasticsearch/reference/current/modules.html
• https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-update-settings.html

[majormoses]

It still seems to default to true?

Hmm maybe you are right and it does still default to true someone must have luckily set this on the new production cluster without updating the others and so I wrongly assumed that in ES 6 they changed the default from false -> true.

https://github.com/elastic/elasticsearch/blob/v6.2.4/server/src/main/java/org/elasticsearch/action/support/DestructiveOperations.java#L37

So I guess there are two separate issues to discuss:

• changing the default from false -> true
• changing the "module" to be static to prevent someone from changing this after cluster initialization or without a rolling restart

The are both clearly breaking changes and the question is whether we should do them in the same major release of if they should be done as two separate major releases. I personally feel that the first step is to change the default as it will ease the transition for production systems by allowing them to set it without needing a cluster restart or re-initializing the cluster and then should change this in the next major after that.

I have seen at more than one Elasticsearch shop drop all indices in production with a bad ad-hoc query before putting that in place and its a very sane default stance which you can always configure later if you perform a rolling restart so it can not be enabled/disabled right before/after a particular query.

If you honestly need to drop (_all|*) (can't see a real use case other than testing) you can easily have a query builder return a list of indices and you can delete them, point being you need an extra hoop to jump through to do something so dangerous.

[jasontedor]

Thanks for clarifying. Each module has (possibly) multiple settings, some of which are static and some of which are dynamic. Currently action.destructive_requires_name is a dynamic setting and your request translates to requesting that it be a static setting.

[majormoses]

I guess its now a 2 part request originally it was to only change it to a static setting but after discovering that it still defaults to false I suggest we change this as well. These would both be breaking changes (major version change) and could be spread across 2 major versions if needed to make the transition smoother.

[gwbrown]

As of 7.10.0, the default value of action.destructive_requires_name is still false (although there is an open issue to change that, see #61074) and it still dynamic.

However, we have not had any additional requests to change this setting to a static setting, and if a malicious user has permissions to change cluster settings, there is worse damage they could do than changing this setting with the intent of deleting all indices. I don't believe this is something we intend to do, so I'm going to close this issue. If you disagree and can present a compelling argument why we should make this a static setting, please comment on this issue or open a new one and link to this issue.