Add and require `?acknowledge=true` when performing destructive actions about elasticsearch HOT 5 CLOSED

Pinging @elastic/es-core-infra (Team:Core/Infra)

from elasticsearch.

First concern would be a breaking change for automated or established API usage, but introducing an optional safety setting users could turn on to require confirmation/parameter might be something immediately useful, if it was at either cluster level or index level then it might be flexible, but also having it set at user level would be really handy to then avoid it for automation/service accounts and enable it for less skilled or higher risk users/groups,etc.

from elasticsearch.

Yeah it's gonna be a breaking change, so we could do it step by step, by having such a framework first and then decide when to use it :)

from elasticsearch.

I think we should not make this change in the ES API itself. Leaving aside the enormous breaking effect it'd have on clients, it's not just these two endpoints: really a lot of the API surface has an irreversibly destructive effect. If we started down this path we'd end up wanting to add the same functionality almost everywhere. But then folks would quickly start wanting to add this option automatically in whatever tooling they're using to call ES for the sake of convenience, and then we're back to the original situation again. I saw this in a previous role: someone even proposed a second ?really_acknowledge=true option because the first acknowledgement was being skipped so much.

Instead, if we think some actions need extra acknowledgement when run directly by a user, let's build that acknowledgement step into the interface that the user is using without disturbing the underlying API. For instance, the Kibana dev tools could require a confirmation on all DELETE actions.

from elasticsearch.

Thanks! Fair enough. Let's keep this in kibana side then: elastic/kibana#182934

from elasticsearch.