重要: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 当前版本文档。
Elasticsearch Guide [7.7] » Set up a cluster for high availability » Back up a cluster » Restore a cluster’s security configuration
« Back up a cluster’s security configuration Restore a cluster’s data »

Restore a cluster’s security configurationedit

You can restore a snapshot of the .security index only if it was created in a previous minor version in the same major version. The last minor version of every major release can convert and read formats of the index for both its major version and the next one.

When you restore security configuration you have the option of doing a complete restore of all configurations, including non-security ones, or to only restore the contents of the .security index. As described in Back up index-based security configuration, the second option comprises only resource-type configurations. The first option has the advantage of restoring a cluster to a clearly defined state from a past point in time. The second option touches only security configuration resources, but it does not completely restore the security features.

To restore your security configuration from a backup, first make sure that the repository holding .security snapshots is installed:

GET /_snapshot/my_backup
GET /_snapshot/my_backup/snapshot_1

Then log into one of the node hosts, navigate to Elasticsearch installation directory, and follow these steps:

  1. Add a new user with the superuser built-in role to the file realm.

    For example, create a user named restore_user:

    bin/elasticsearch-users useradd restore_user -p password -r superuser

  2. Using the previously created user, delete the existing .security-6 or .security-7 index.

    curl -u restore_user -X DELETE "localhost:9200/.security-*"

    After this step any authentication that relies on the .security index will not work. This means that all API calls that authenticate with native or reserved users will fail, as will any user that relies on a native role. The file realm user we created in the step above will continue to work because it is not stored in the .security index and uses the built-in superuser role.

  3. Using the same user, restore the .security index from the snapshot.

     curl -u restore_user -X POST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore" -H 'Content-Type: application/json' -d'
 {
    "indices": ".security-*",
    "include_global_state": true 
 }
 '

    The include_global_state: true is mandatory only for a complete restore. This will restore the global cluster metadata, which contains configuration information for the complete cluster. If you set this to false, it recovers only the contents of the .security index, such as usernames and password hashes, API keys, application privileges, role and role mapping definitions.
  4. Optionally, if you need to review and override the settings that were included in the snapshot (by the include_global_state flag), cherry-pick and apply the persistent settings that you have extracted with the GET _cluster/settings API.

  5. If you pursue a complete point in time restore of the cluster, you also have to restore configuration files. Again, this will restore non-security settings as well.

    This entails a straight-up filesystem copy of the backed up configuration files, overwriting the contents of $ES_PATH_CONF, and restarting the node. This needs to be done on every node. Depending on the extent of the differences between your current cluster configuration and the restored configuration, you may not be able to perform a rolling restart. If you are performing a full restore of your configuration directory, we recommend a full cluster restart as the safest option. Alternatively, you may wish to restore your configuration files to a separate location on disk and use file comparison tools to review the differences between your existing configuration and the restored configuration.

« Back up a cluster’s security configuration Restore a cluster’s data »