Cannot restore index [.security-7]

Elastic Stack Elasticsearch
,
1

Hello everyone,

I'm trying to migrate all my users from my old 7.9 cluster to a new 8.5 cluster.

I was reviewing the documentation and proceeded to take a snapshot of the security indexes of my old cluster to be able to do a restore in my new cluster, at first glance it sounds easy... but no.

I have created a repository where the old cluster leaves its snapshot and the new cluster can take them.

GET _snapshot
{
  "test": {
    "type": "fs",
    "settings": {
      "location": "/elastic_backups/migracion-snap"
    }
  }
}

GET _cat/snapshots
snap1 test SUCCESS 1677856088 15:08:08 1677856090 15:08:10 1.6s 1 1 0 1

At first glance, everything seems to be ready to perform a restore to said snapshot.

POST _snapshot/test/snap1/_restore
{
  "indices": ".security*",
  "ignore_unavailable": true,
  "include_global_state": false,
  "include_aliases": false
}

{
  "error": {
    "root_cause": [
      {
        "type": "snapshot_restore_exception",
        "reason": "[test:snap1/dj3QZOk6RiiM8RSHaljugQ] cannot restore index [.security-7] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"
      }
    ],
    "type": "snapshot_restore_exception",
    "reason": "[test:snap1/dj3QZOk6RiiM8RSHaljugQ] cannot restore index [.security-7] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"
  },
  "status": 500
}

I try to delete or close the index

DELETE .security-7
{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:admin/delete] is unauthorized for user [elastic] with effective roles [superuser] on restricted indices [.security-7], this action is granted by the index privileges [delete_index,manage,all]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:admin/delete] is unauthorized for user [elastic] with effective roles [superuser] on restricted indices [.security-7], this action is granted by the index privileges [delete_index,manage,all]"
  },
  "status": 403
}

POST .security-7/_close
{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:admin/close] is unauthorized for user [elastic] with effective roles [superuser] on restricted indices [.security-7], this action is granted by the index privileges [manage_follow_index,manage,all]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:admin/close] is unauthorized for user [elastic] with effective roles [superuser] on restricted indices [.security-7], this action is granted by the index privileges [manage_follow_index,manage,all]"
  },
  "status": 403
}

I also clarify that I create a user with all the roles, create new roles with [manage_follow_index,manage,all] but I was not successful.

If someone please has some documentation to be able to perform a clean migration from an old cluster to a new one, I would be very grateful if you share it with me.

2

To work on the restricted indices you need to create a special role see here

"allow_restricted_indices": true

Restricted indices are a special category of indices that are used internally to store configuration data and should not be directly accessed. Only internal system roles should normally grant privileges over the restricted indices. Toggling this flag is very strongly discouraged because it could effectively grant unrestricted operations on critical data, making the entire system unstable or leaking sensitive information. If however, for administrative purposes, you need to create a role with privileges covering restricted indices, you must set this field to true (default is false), and then the names field will cover the restricted indices as well.

Also I am pretty sure you do not actually need to restore that index into your new cluster as it is more of a "definitions" index not an updated index if that makes sense.

3

Thank you very much for your reply. I'm going to try today

If this is not necessary, how can I migrate my users?

4

Apologies I do not understand....

If you want to work with restricted indices you will need that setting. Just protect that user/role and only use it when necessary.

5

For some reason it doesn't work

GET _security/role/SUPERMAN

{
  "SUPERMAN": {
    "cluster": [
      "all"
    ],
    "indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "all",
          "manage",
          "manage_follow_index"
        ],
        "field_security": {
          "grant": [
            "*"
          ],
          "except": []
        },
        "allow_restricted_indices": false
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "space_all"
        ],
        "resources": [
          "space:default"
        ]
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
  }
}

POST .security-7/_close

{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:admin/close] is unauthorized for user [gverdugo] with effective roles [SUPERMAN] on restricted indices [.security-7], this action is granted by the index privileges [manage_follow_index,manage,all]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:admin/close] is unauthorized for user [gverdugo] with effective roles [SUPERMAN] on restricted indices [.security-7], this action is granted by the index privileges [manage_follow_index,manage,all]"
  },
  "status": 403
}
6

Try

        "names": [
          "*",
          ".*" <!--- This 
        ],
7

I omitted that index too, thank you very much.

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.