Operator privileges for snapshot and restoreedit
This feature is designed for indirect use by Elasticsearch Service, Elastic Cloud Enterprise, and Elastic Cloud on Kubernetes. Direct use is not supported.
Invoking operator-only APIs or updating operator-only dynamic cluster settings typically results in changes in the cluster state. The cluster state can be included in a cluster snapshot. Snapshots are a great way to preserve the data of a cluster, which can later be restored to bootstrap a new cluster, perform migration, or disaster recovery, for example. In a traditional self-managed environment, the intention is for the restore process to copy the entire cluster state over when requested. However, in a more managed environment, such as Elasticsearch Service, data that is associated with operator-only functionality is explicitly managed by the infrastructure code.
Restoring snapshot data associated with operator-only functionality could be problematic because:
- A snapshot could contain incorrect values for operator-only functionalities. For example, the snapshot could have been taken in a different cluster where requirements are different or the operator privileges feature is not enabled. Restoring data associated with operator-only functionality breaks the guarantee of operator privileges.
- Even when the infrastructure code can correct the values immediately after a restore, there will always be a short period of time when the cluster could be in an inconsistent state.
- The infrastructure code prefers to configure operator-only functionality from a single place, that is to say, through API calls.
Therefore, when the operator privileges feature is enabled, snapshot data that is associated with any operator-only functionality is not restored.
That information is still included when taking a snapshot so that all data is always preserved.