Spec-Zone.ru › Elasticsearch 8
›Руководство по Elasticsearch [8.17] ›Настройка Elasticsearch ›Удаленные кластеры

Миграция удаленных кластеров с сертификатной на API-ключевую аутентификацию

Модель безопасности удаленных кластеров на основе API-ключа предоставляет администраторам более точный контроль доступа по сравнению с моделью на основе TLS-сертификатов. По этой причине вы можете захотеть мигрировать с сертификатной модели на модель с API-ключами.

Хотя возможно мигрировать, определив новое подключение удалённого кластера с использованием нового псевдонима, это имеет несколько недостатков:

  • Для кросс-кластерной репликации невозможно изменить псевдоним лидера кластера для существующих задач. В результате, с новым удалённым кластером, индексы-фолловеры необходимо будет воссоздать с нуля.
  • Для кросс-кластерного поиска, задач трансформации и обнаружения аномалий разрешено обновление псевдонима удалённого кластера. Однако, если задача была создана с подстановками, например *:source_index, и superuser, добавление нового удалённого кластера заставит задачу выполнить в два раза больше работы и, потенциально, исказит результаты с дубликатами.

По этим причинам, вы можете предпочесть мигрировать удалённый кластер непосредственно, выполнив следующие шаги:

  1. Проверьте предварительные условия
  2. Перенастройте удаленный кластер и сгенерируйте кросс-кластерный API-ключ
  3. Остановите кросс-кластерные операции
  4. Подключитесь к удалённому кластеру
  5. Возобновите кросс-кластерные операции
  6. Отключите сертификатную аутентификацию и авторизацию

Если у вас возникнут какие-либо проблемы, обратитесь к Отладке.

Предварительные условия

  • Узлы локального и удаленного кластеров должны быть версии 8.10 или выше.
  • Локальный и удаленный кластеры должны иметь соответствующую лицензию. Для получения дополнительной информации обратитесь к https://www.elastic.co/subscriptions.

Перенастройка удаленного кластера и генерация кросс-кластерного API-ключа

На удалённом кластере:

  1. Включите сервер удаленного кластера на каждом узле удаленного кластера. В elasticsearch.yml:

    1. Установите remote_cluster_server.enabled на значение true.
    2. Настройте адрес привязки и публикации для трафика сервера удаленного кластера, например, с помощью remote_cluster.host. Без настройки адреса трафик удаленного кластера может быть привязан к локальному интерфейсу, и удалённые кластеры, работающие на других машинах, не смогут подключиться.
    3. Необязательно, настройте порт удаленного сервера с помощью remote_cluster.port (по умолчанию 9443).

  2. Далее, сгенерируйте центр сертификации (ЦС) и пару серверного сертификата/ключа. На одном из узлов удалённого кластера, из каталога, где установлен Elasticsearch:

    1. Создайте ЦС, если у вас его ещё нет:

      ./bin/elasticsearch-certutil ca --pem --out=cross-cluster-ca.zip --pass CA_PASSWORD

      Замените CA_PASSWORD на пароль, который вы хотите использовать для ЦС. Вы можете убрать опцию --pass и её аргумент, если вы не разворачиваете систему в производственной среде.

    2. Разархивируйте сгенерированный файл cross-cluster-ca.zip. Этот сжатый файл содержит следующее содержимое:

      /ca
|_ ca.crt
|_ ca.key

    3. Сгенерируйте пару сертификата и закрытого ключа для узлов в удалённом кластере:

      ./bin/elasticsearch-certutil cert --out=cross-cluster.p12 --pass=CERT_PASSWORD --ca-cert=ca/ca.crt --ca-key=ca/ca.key --ca-pass=CA_PASSWORD --dns=example.com --ip=127.0.0.1
      • Замените CA_PASSWORD на пароль ЦС из предыдущего шага.
      • Замените CERT_PASSWORD на пароль, который вы хотите использовать для сгенерированного закрытого ключа.
      • Используйте опцию --dns, чтобы указать соответствующее имя DNS для сертификата. Вы можете указать её несколько раз для нескольких DNS.
      • Используйте опцию --ip, чтобы указать соответствующий IP-адрес для сертификата. Вы можете указать её несколько раз для нескольких IP-адресов.

    4. Если удалённый кластер имеет несколько узлов, вы можете:

      • создать один универсальный сертификат для всех узлов;
      • или создать отдельные сертификаты для каждого узла вручную или в пакетном режиме с помощью бесшумного режима.

  3. На каждом узле удалённого кластера:

    1. Скопируйте файл cross-cluster.p12 из предыдущего шага в каталог config. Если вы не создавали универсальный сертификат, убедитесь, что копируете правильный узловой файл p12.

    2. Добавьте следующую конфигурацию в elasticsearch.yml:

      xpack.security.remote_cluster_server.ssl.enabled: true
xpack.security.remote_cluster_server.ssl.keystore.path: cross-cluster.p12

    3. Добавьте пароль хранилища ключей SSL в хранилище ключей Elasticsearch:

      ./bin/elasticsearch-keystore add xpack.security.remote_cluster_server.ssl.keystore.secure_password

      Когда появится запрос, введите пароль CERT_PASSWORD из предыдущего шага.

  4. Перезапустите удалённый кластер.
  5. На удалённом кластере сгенерируйте кросс-кластерный API-ключ, обеспечивающий доступ к индексам, которые вы хотите использовать для кросс-кластерного поиска или кросс-кластерной репликации. Вы можете использовать API создания кросс-кластерного API-ключа или Kibana.
  6. Скопируйте закодированный ключ (encoded в ответе) в безопасное место. Вам понадобится он для подключения к удалённому кластеру позже.

Остановка кросс-кластерных операций

На локальном кластере остановите любые постоянные задачи, которые ссылаются на удалённый кластер:

  • Используйте API остановки трансформаций для остановки любых трансформаций.
  • Используйте API закрытия задач для закрытия любых задач обнаружения аномалий.
  • Используйте API приостановки шаблона автоматического следования для приостановки любых автоматических кросс-кластерных реплиций.
  • Используйте API приостановки фолловера для приостановки любых ручных кросс-кластерных реплиций или существующих индексов, которые были созданы из шаблона автоматического следования.

Подключение к удалённому кластеру

В локальном кластере:

  1. Улучшите любые роли, используемые пользователями локального кластера, с необходимыми привилегиями на удалённые индексы или привилегиями на удалённый кластер для кросс-кластерной репликации и кросс-кластерного поиска. Обратитесь к разделу Настройка ролей и пользователей. Примечание:

    • Вам нужно назначить дополнительные remote_indices или remote_cluster привилегии только существующим ролям, используемым для кросс-кластерных операций. Вы должны иметь возможность скопировать эти привилегии из исходных ролей на удалённом кластере, где они определены в модели безопасности на основе сертификатов.
    • Роли в локальном кластере не могут превышать привилегию access, предоставленную API-ключом для кросс-кластерных операций. Любые дополнительные локальные привилегии будут подавлены привилегиями API-ключа кросс-кластера.
    • Обновление не требуется, если задачи кросс-кластерной репликации или кросс-кластерного поиска были настроены с помощью роли superuser. Роль superuser автоматически обновляется, разрешая доступ ко всем удалённым индексам.
    • Задачи, выполняемые обычными пользователями с именованными ролями, немедленно обновляются с новыми привилегиями. Задача загрузит новое определение при следующем запуске.
    • Вам необходимо перезапустить задачи, которые выполняются с помощью API-ключа (это делается на следующем шаге).

  2. Если вы динамически настроили удалённый кластер (через API настроек кластера):

    1. Получите текущую конфигурацию удалённого кластера и сохраните её в надёжном месте. Возможно, она вам потребуется позднее, если потребуется откат. Используйте API настроек кластера:

      resp = client.cluster.get_settings(
    filter_path="persistent.cluster.remote",
)
print(resp)
      response = client.cluster.get_settings(
  filter_path: 'persistent.cluster.remote'
)
puts response
      const response = await client.cluster.getSettings({
  filter_path: "persistent.cluster.remote",
});
console.log(response);
      GET /_cluster/settings?filter_path=persistent.cluster.remote
    2. Удалите существующее определение удалённого кластера, установив настройки удалённого кластера в значение null.
  3. Если вы статически настроили удалённый кластер (через elasticsearch.yml), скопируйте настройки cluster.remote из elasticsearch.yml и сохраните их в надёжном месте. Возможно, они вам потребуются позднее, если потребуется откат.

  4. На каждом узле локального кластера:

    1. Скопируйте файл ca.crt, сгенерированный на удалённом кластере ранее, в каталог config, переименовав файл в remote-cluster-ca.crt.

    2. Добавьте следующую конфигурацию в elasticsearch.yml:

      xpack.security.remote_cluster_client.ssl.enabled: true
xpack.security.remote_cluster_client.ssl.certificate_authorities: [ "remote-cluster-ca.crt" ]

    3. Добавьте API-ключ кросс-кластера, созданный на удалённом кластере ранее, в хранилище ключей:

      ./bin/elasticsearch-keystore add cluster.remote.ALIAS.credentials

      Замените ALIAS тем же псевдонимом, который использовался для кросс-кластерных операций до миграции. При запросе введите закодированный API-ключ кросс-кластера, созданный на удалённом кластере ранее.

  5. Если вы динамически настроили удалённый кластер (через API настроек кластера):

    1. Перезапустите локальный кластер, чтобы загрузить изменения в хранилище ключей и настройки.

    2. Добавьте удалённый кластер повторно. Используйте тот же псевдоним удалённого кластера и измените порт транспорта на порт удалённого кластера. Например:

      resp = client.cluster.put_settings(
    persistent={
        "cluster": {
            "remote": {
                "my_remote": {
                    "mode": "proxy",
                    "proxy_address": "my.remote.cluster.com:9443"
                }
            }
        }
    },
)
print(resp)
      response = client.cluster.put_settings(
  body: {
    persistent: {
      cluster: {
        remote: {
          my_remote: {
            mode: 'proxy',
            proxy_address: 'my.remote.cluster.com:9443'
          }
        }
      }
    }
  }
)
puts response
      const response = await client.cluster.putSettings({
  persistent: {
    cluster: {
      remote: {
        my_remote: {
          mode: "proxy",
          proxy_address: "my.remote.cluster.com:9443",
        },
      },
    },
  },
});
console.log(response);
      PUT /_cluster/settings
{
  "persistent" : {
    "cluster" : {
      "remote" : {
        "my_remote" : { 
          "mode": "proxy",
          "proxy_address": "my.remote.cluster.com:9443" 
        }
      }
    }
  }
}

      Псевдоним удалённого кластера. Используйте тот же псевдоним, который использовался до миграции.

      Адрес удалённого кластера с портом удалённого кластера, который по умолчанию равен 9443.

  6. Если вы статически настроили удалённый кластер (через elasticsearch.yml):

    1. Обновите настройки cluster.remote в elasticsearch.yml на каждом узле локального кластера. Измените порт на порт удалённого кластера, который по умолчанию равен 9443.
    2. Перезапустите локальный кластер, чтобы загрузить изменения в хранилище ключей и настройки.

  7. Используйте API информации об удалённом кластере, чтобы проверить, успешно ли подключился локальный кластер к удалённому кластеру:

    resp = client.cluster.remote_info()
print(resp)
    response = client.cluster.remote_info
puts response
    const response = await client.cluster.remoteInfo();
console.log(response);
    GET /_remote/info

    Ответ API должен указывать, что локальный кластер подключился к удалённому кластеру:

    {
  "my_remote": {
    "connected": true, 
    "mode": "proxy",
    "proxy_address": "my.remote.cluster.com:9443",
    "server_name": "",
    "num_proxy_sockets_connected": 0,
    "max_proxy_socket_connections": 18,
    "initial_connect_timeout": "30s",
    "skip_unavailable": false,
    "cluster_credentials": "::es_redacted::" 
  }
}

    Удалённый кластер подключён.

    Если присутствует, указывает, что удалённый кластер подключился с помощью аутентификации по API-ключу.

Возобновление кросс-кластерных операций

Возобновите любые непрерывные задачи, которые вы приостановили ранее. Задачи должны быть перезапущены тем же пользователем или API-ключом, который создал задачу до миграции. Убедитесь, что роли этого пользователя или API-ключа обновлены с необходимыми remote_indices или remote_cluster привилегиями. Для пользователей задачи сохраняют учетные данные вызывающего при запуске и работают в контексте безопасности этого пользователя. Для API-ключей перезапуск задачи обновит задачу с обновлённым API-ключом.

  • Используйте API Старт преобразования, чтобы запустить любые преобразования.
  • Используйте API Открыть задачи, чтобы открыть любые задачи обнаружения аномалий.
  • Используйте API Возобновить следование, чтобы возобновить любую автоматическую кросс-кластерную репликацию.
  • Используйте API Возобновить шаблон автоматического следования, чтобы возобновить любую ручную кросс-кластерную репликацию или существующие индексы, которые были созданы из шаблона автоматического следования.

Отключение аутентификации и авторизации на основе сертификатов

Переходите к этому шагу только в том случае, если миграция успешно завершена в локальном кластере. Если миграция не удалась, либо выясните причину проблемы и попытайтесь её исправить, либо произведите откат.

Далее отключите подключение на основе сертификатов. По желанию вы также можете аннулировать авторизацию.

  1. Нет специальной настройки для включения или отключения кросс-кластерного соединения на основе сертификатов, потому что оно использует тот же протокол транспорта, что и межузловая коммуникация внутри кластера.

    Администратор удалённого кластера может остановить подключение существующего локального кластера, изменив доверие к TLS. Точные шаги зависят от конфигурации кластеров. Общим решением является восстановление CA и сертификата/ключа, используемого удалённым интерфейсом транспорта, чтобы любой существующий сертификат/ключ, локально или распределённо, больше не считался надёжным.

    Другим решением является применение IP-фильтров к интерфейсу транспорта, блокируя трафик извне кластера.

  2. По желанию удалите любые роли на удалённом кластере, которые использовались только для кросс-кластерных операций. Эти роли больше не используются в модели безопасности на основе API-ключа.

Откат

Если требуется откат, выполните следующие шаги на локальном кластере:

  1. Остановите все постоянные задачи, ссылающиеся на удаленный кластер.
  2. Удалите определение удаленного кластера, установив параметры удаленного кластера в null.
  3. Удалите привилегии remote_indices или remote_cluster из любых ролей, которые были обновлены во время миграции.
  4. На каждом узле удалите настройки remote_cluster_client.ssl.* из elasticsearch.yml.
  5. Перезапустите локальный кластер, чтобы применить изменения к хранилищу ключей и elasticsearch.yml.
  6. На локальном кластере примените исходные настройки удаленного кластера. Если соединение с удаленным кластером настроено статически (с использованием файла elasticsearch.yml), перезапустите кластер.
  7. Используйте API информации о удаленном кластере, чтобы проверить, что локальный кластер подключился к удаленному кластеру. Ответ должен содержать "connected": true и не должен содержать "cluster_credentials": "::es_redacted::".
  8. Перезапустите любые постоянные задачи, которые вы остановили ранее.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/8.17/remote-clusters-migrate.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API