Spec-Zone.ru › Elasticsearch 7
›Руководство по Elasticsearch [7.17] ›Защита Elastic Stack ›Обновление сертификатов безопасности узлов

Обновление сертификатов с использованием того же центра сертификации

Данная процедура предполагает, что у вас есть доступ к сертификату и ключу центра сертификации, который был первоначально сгенерирован (или иным образом хранится вашей организацией) и использовался для подписи сертификатов узлов, которые используются в настоящее время. Она также предполагает, что клиенты, подключающиеся к Elasticsearch по HTTP-слою, настроены на доверие сертификату центра сертификации.

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

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

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

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

Если ваш центр сертификации изменился, выполните шаги в обновлении сертификатов безопасности с использованием другого центра сертификации.

Генерация нового сертификата для транспортного уровня

В следующих примерах используются файлы PKCS#12, но те же шаги применяются к хранилищам ключей JKS.

  1. Откройте файл ES_PATH_CONF/elasticsearch.yml и проверьте имена и расположения хранилищ ключей, которые сейчас используются. Вы будете использовать те же имена для нового сертификата.

    В этом примере хранилище ключей и хранилище доверенных сертификатов указывают на разные файлы. Ваша конфигурация может использовать один и тот же файл, который содержит и сертификат, и CA. В этом случае укажите путь к этому файлу для хранилища ключей и хранилища доверенных сертификатов.

    Эти инструкции предполагают, что предоставленный сертификат подписан доверенным центром сертификации, а режим проверки установлен на certificate. Эта настройка гарантирует, что узлы не пытаются выполнить проверку имени хоста.

    xpack.security.transport.ssl.keystore.path: config/elastic-certificates.p12
xpack.security.transport.ssl.keystore.type: PKCS12
xpack.security.transport.ssl.truststore.path: config/elastic-stack-ca.p12
xpack.security.transport.ssl.truststore.type: PKCS12
xpack.security.transport.ssl.verification_mode: certificate

  2. Используя ваш существующий CA, сгенерируйте хранилище ключей для ваших узлов. Вы должны использовать CA, который использовался для подписи текущего сертификата.

    ./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
    Параметры команды
    --ca <ca_file>
    Имя хранилища ключей CA, используемого для подписи ваших сертификатов. Если вы использовали инструмент elasticsearch-certutil для генерации вашего существующего CA, имя хранилища ключей по умолчанию равно elastic-stack-ca.p12.
    1. Введите имя выходного файла или примите значение по умолчанию elastic-certificates.p12.
    2. При запросе введите пароль для хранилища ключей узла.

  3. Если вы ввели пароль при создании хранилища ключей узла, который отличается от текущего пароля хранилища ключей, выполните следующую команду для сохранения пароля в хранилище ключей Elasticsearch:

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

  4. На текущем узле вашего кластера, где вы обновляете хранилище ключей, запустите постепенный перезапуск.

    Остановитесь на шаге, указывающем Выполните все необходимые изменения, а затем переходите к следующему шагу в этой процедуре.

  5. Замените существующее хранилище ключей новым хранилищем ключей, убедившись, что имена файлов совпадают. Например, elastic-certificates.p12.

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

  6. Если вам нужно было сохранить новое хранилище ключей с новым именем файла, обновите файл ES_PATH_CONF/elasticsearch.yml, чтобы использовать имя файла нового хранилища ключей. Например:

    xpack.security.transport.ssl.keystore.path: config/elastic-certificates.p12
xpack.security.transport.ssl.keystore.type: PKCS12
xpack.security.transport.ssl.truststore.path: config/elastic-stack-ca.p12
xpack.security.transport.ssl.truststore.type: PKCS12
  7. Запустите узел, на котором вы обновили хранилище ключей.

  8. (Необязательно) Используйте API сертификатов SSL, чтобы проверить, что Elasticsearch загрузил новое хранилище ключей.

    GET /_ssl/certificates

  9. Если вы обновляете только сертификаты для транспортного уровня (а не HTTP-уровня), то выполните шаг 4 до шага 8 по одному узлу за раз, пока не обновите все хранилища ключей в вашем кластере. Затем вы можете выполнить оставшиеся шаги для постепенного перезапуска.

    В противном случае не выполняйте постепенный перезапуск. Вместо этого переходите к шагам генерации нового сертификата для HTTP-уровня.

Что дальше?

Отлично! Вы обновили хранилище ключей для транспортного уровня. Вы также можете обновить хранилище ключей для HTTP-уровня, если необходимо. Если вы не обновляете хранилище ключей для HTTP-уровня, то всё готово.

Генерация нового сертификата для HTTP-слоя

Другие компоненты, такие как Kibana или любые клиенты Elastic на языках программирования, проверяют этот сертификат при подключении к Elasticsearch.

Если в вашей организации есть собственный центр сертификации (ЦС), вам нужно будет сгенерировать запросы на подпись сертификата (CSR). CSR содержат информацию, которую ваш ЦС использует для генерации и подписания сертификата.

  1. На любом узле вашего кластера, где установлен Elasticsearch, запустите утилиту Elasticsearch HTTP-сертификатов.

    ./bin/elasticsearch-certutil http

    Эта команда сгенерирует файл .zip, содержащий сертификаты и ключи для использования с Elasticsearch и Kibana. В каждой папке находится файл README.txt, объясняющий, как использовать эти файлы.

    1. При запросе о желании сгенерировать CSR, введите n.
    2. При запросе о желании использовать существующий ЦС, введите y.
    3. Введите абсолютный путь к вашему ЦС, например, путь к файлу elastic-stack-ca.p12.
    4. Введите пароль для вашего ЦС.
    5. Введите срок действия вашего сертификата. Вы можете ввести срок действия в годах, месяцах или днях. Например, введите 1y для одного года.

    6. При запросе о желании сгенерировать один сертификат на узел, введите y.

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

    7. При запросе введите имя первого узла в вашем кластере. Рекомендуется использовать то же имя узла, что и значение параметра node.name в файле elasticsearch.yml.

    8. Введите все имена хостов, используемые для подключения к вашему первому узлу. Эти имена хостов будут добавлены в качестве имен DNS в поле Subject Alternative Name (SAN) вашего сертификата.

      Перечислите все имена хостов и их варианты, используемые для подключения к вашему кластеру через HTTPS.

    9. Введите IP-адреса, которые клиенты могут использовать для подключения к вашему узлу.
    10. Повторите эти шаги для каждого дополнительного узла в вашем кластере.
  2. После генерации сертификата для каждого вашего узла, введите пароль для вашего закрытого ключа, когда вас попросят.

  3. Разархивируйте сгенерированный файл elasticsearch-ssl-http.zip. Этот сжатый файл содержит две директории; по одной для Elasticsearch и Kibana. Внутри директории /elasticsearch находится директория для каждого узла с собственным файлом http.p12. Например:

    /node1
|_ README.txt
|_ http.p12
|_ sample-elasticsearch.yml
    /node2
|_ README.txt
|_ http.p12
|_ sample-elasticsearch.yml
    /node3
|_ README.txt
|_ http.p12
|_ sample-elasticsearch.yml
  4. При необходимости переименуйте файл http.p12, чтобы он соответствовал имени вашего существующего сертификата для HTTP-клиентских коммуникаций. Например, node1-http.p12.

  5. На текущем узле вашего кластера, где вы обновляете хранилище ключей, запустите постепенную перезагрузку.

    Остановитесь на шаге, указывающем Выполните все необходимые изменения, затем переходите к следующему шагу этой процедуры.

  6. Замените ваше существующее хранилище ключей новым хранилищем, убедившись, что имена файлов совпадают. Например, node1-http.p12.

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

  7. Если вам нужно было сохранить новое хранилище ключей с новым именем файла, обновите файл ES_PATH_CONF/elasticsearch.yml, чтобы использовать имя файла нового хранилища ключей. Например:

    xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: node1-http.p12

  8. Если пароль вашего хранилища ключей меняется, добавьте пароль к вашему закрытому ключу в безопасные настройки Elasticsearch.

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

  9. Запустите узел, где вы обновили хранилище ключей.

    Используйте API «cat nodes», чтобы подтвердить, что узел присоединился к кластеру:

    GET _cat/nodes

  10. (Необязательно) Используйте API SSL-сертификатов, чтобы проверить, что Elasticsearch загрузил новое хранилище ключей.

    GET /_ssl/certificates
  11. По одному узлу за раз выполните шаги с 5 по 10, пока не обновите все хранилища ключей в вашем кластере.
  12. Завершите оставшиеся шаги для постепенной перезагрузки, начиная с шага Возобновить распределение фрагментов.

© 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/7.17/update-node-certs-same.html

Spec-Zone.ru

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