Version: 7.x-47.0.0
Community

Aliases, snapshots and restore

Index alias handling

Before applying any security checks, Search Guard first resolves any alias to the concrete index name(s). Index aliases are thus transparent to Search Guard. The same is true for

  • Index wildcards, also with multiple index names
    • e.g. https://localhost:9200/i*ex*,otherindex/_search
  • Date math index names
    • e.g. https://localhost:9200/<logstash-{now/d}>/_search/_search
  • Filtered index aliases

Index names are resolved to their concrete index name(s) in

  • REST requests
  • Transport requests
  • Search Guard role definitions

In practice this means that you do not need to grant permissions on index aliases in addition to granting permission on the concrete index names. For example, if you have an index alias myalias pointing to an index myindex, you only need to configure permissions for myindex. These permissions apply regardless whether the user accesses the index via myalias or myindex.

In detail, for every request Search Guard

  • resolves any index name(s) in the request to the concrete index name(s)
  • resolves any index name(s) in the user’s role definitions to the concrete index name(s)
  • applies permission checks based on the concrete index name(s)

Handling filtered index aliases

Filtered index aliases currently do not work if the do_not_fail_on_forbidden flag is set to true in sg_config.yml.

Filtered index aliases can be used to filter documents from the underlying concrete index. However, using filteres aliases is not a secure way to restrict access to certain documents. In order to do that, please use the Document Level Security feature of Search Guard.

Because of this potential security leak, Search Guard detects and treats filtered index aliases in a special way: You can either disallow them completely, or issue a warning message on WARN or DEBUG level.

The following entry in sg_config can be used to configure this:

---
_sg_meta:
  type: "config"
  config_version: 2

 sg_config:
    dynamic:		    
      filtered_alias_mode: <warn|nowarn|disallow>
Name Description
warn default, logs a warning message if multiple filtered index aliases are detected on WARN level
disallow forbids multiple filtered index aliases completely
nowarn logs a warning message if multiple filtered index aliases are detected on DEBUG level

Required permissions

In order to perform snapshot and restore operations, the user must be assigned to the built-in SGS_MANAGE_SNAPSHOTS role.

Restoring a snapshot

A snapshot can only be restored if it does not contain global state and it does not contain the ‘searchguard’ index.

In order to restore indices from a snapshot that does contain global state, you need to exclude it when performing the restore. If your snapshot also contains the Search Guard index, list the indices to restore explicitely:

POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "humanresources",  
  "include_global_state": false
}

It is recommended to exclude the Search Guard index from all snapshots globally.

Snapshot and Restore: Search Guard index

The Search Guard configuration index contains sensitive data like user, role and permission information.

Restoring the Search Guard configuration index from a snapshot is only allowed if an admin certificate is used.

For curl, you need to specify the admin certificate with it’s complete certificate chain and the key like:

curl --insecure --cert chain.pem --key kirk.key.pem -XPOST '<host>:9200/_snapshot/my_backup/snapshot_1/_restore?pretty'


Not what you were looking for? Try the search.