Безопасность коммуникации в кластере#

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

Аутентификация узлов в кластере (shared secret)#

CedrusData позволяет аутентифицировать узлы в кластере путем проверки специального параметра конфигурации, называемого shared secret. Если значение shared secret worker-узла совпадает со значением shared secret coordinator-узла, worker-узел будет успешно аутентифицирован в кластере. В противном случае worker-узел не будет аутентифицирован и не присоединится к кластеру.

Использование shared secret обязательно в следующих случаях:

Если вы собираетесь включить шифрование трафика между узлами с помощью TLS.
Если вы собираетесь использовать внешнюю аутентификацию пользователей в кластере CedrusData.

Значение shared secret необходимо установить на всех узлах кластера с помощью параметра internal-communication.shared-secret в файле config.properties:

internal-communication.shared-secret=<secret>

Мы рекомендуем использовать в качестве shared secret случайные строки большой длины. В операционных системах семейства Linux вы можете воспользоваться следующей командой для генерации случайной строки:

openssl rand 512 | base64 | tr --delete '\n' && echo ""

Проверка работы shared secret#

Проделайте следующие шаги для проверки работы аутентификации узлов с помощью shared secret:

Запустите один coordinator-узел и один или несколько worker-узлов. Все узлы должны иметь одинаковое значение internal-communication.shared-secret. Убедитесь, что все запущенные узлы смогли присоединиться к кластеру с помощью SQL-запроса:
```
SELECT * FROM system.runtime.nodes;
```
Измените значение internal-communication.shared-secret на одном из worker-узлов и перезапустите его. Убедитесь c помощью того же SQL-запроса, что количество узлов в кластере уменьшилось на единицу, так как перезапущенный worker-узел не может присоединиться к кластеру из-за несовпадения значения shared secret.
Верните изначальное значение internal-communication.shared-secret на worker-узле и перезапустите его. Убедитесь с помощью того же SQL-запроса, что количество узлов вернулось к изначальному значению, так как worker-узел был успешно аутентифицирован в кластере.

Вы так же можете проверить количество worker-узлов в кластере с помощью Web UI.

Шифрование трафика между узлами с помощью TLS#

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

Обратите внимание, что настройки ниже обеспечивают зашифрованную коммуникацию только между узлами кластера CedrusData. Для шифрования трафика между клиентами CedrusData и coordinator-узлом необходима отдельная настройка TLS на coordinator-узле.

Для включения TLS между узлами CedrusData измените конфигурацию в файле config.properties следующим образом:

Убедитесь, что включена Аутентификация узлов в кластере (shared secret).
Включите автоматическое создание и проверку сертификатов:
```
internal-communication.https.required=true
```

Включите HTTPS на всех узлах:

http-server.https.enabled=true
http-server.https.port=<https port>

Измените discovery.uri так, что бы был использован протокол HTTPS. Обратите внимание, что при включенном TLS-шифровании между узлами в качестве адреса координатора можно использовать только IP-адрес. Hostname и FQDN (fully qualified domain name) не поддерживаются.
```
discovery.uri=https://<coordinator ip address>:<https port>
```
Перезапустите все узлы CedrusData. Узлы CedrusData автоматически создадут необходимые сертификаты и начнут шифровать внутренний трафик.

Предупреждение

В более старых версиях Trino требовалось ручное создание сертификатов узлов. Если вы мигрируете с более старых версий, удалите следующие параметры конфигурации из файла config.properties:

internal-communication.https.keystore.path
internal-communication.https.truststore.path
node.internal-address-source

Влияние на производительность#

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

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

Для запросов, которые передают существенное количество данных между узлами или значительно нагружают CPU, падение производительности может быть более существенным, от 10% и более.

Дополнительная настройка производительности#

В некоторых случаях изменение источника случайных значений может существенно улучшить производительность.

По умолчанию TLS шифрование использует системное устройство /dev/urandom в качестве источника энтропии. Данное устройство имеет ограниченную пропускную способность, и потому может стать узким местом в случае использования высокоскоростных сетей (например, InfiniBand). В таких случаях мы рекомендуем попробовать изменить источник энтропии на SHA1PRNG в файле config.properties на всех узлах кластера:

http-server.https.secure-random-algorithm=SHA1PRNG

Обратите внимание, что данный источник энтропии получает изначальное seed значение из блокирующего устройства /dev/random, что так же может оказать негативное влияние на производительность. Для устройств, которые не могут обеспечить достаточно быструю генерацию seed значений из /dev/random, вы можете изменить источник энтропии на /dev/urandom путем добавления следующей строки в файл jvm.config:

-Djava.security.egd=file:/dev/urandom