Защищенная внутренняя коммуникация#

Кластер Trino можно настроить на использование защищенной связи с внутренней аутентификацией узлов кластера и, при необходимости, с дополнительной защитой на основе TLS.

Настройка общего секрета#

Необходимо настроить общий секрет для аутентификации всего обмена данными между узлами кластера в следующих сценариях:

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

Задайте общий секрет с одинаковым значением в config.properties на всех узлах кластера:

internal-communication.shared-secret=<secret>

Рекомендуется использовать длинный случайный ключ, который можно сгенерировать следующей командой Linux:

openssl rand 512 | base64

Проверка конфигурации#

Чтобы проверить конфигурацию общего секрета:

Запустите кластер Trino с двумя или более узлами, настроенными с общим секретом.
Подключитесь к Web UI.
Убедитесь, что число ACTIVE WORKERS равно числу узлов, настроенных с вашим общим секретом.
Измените значение общего секрета на одном worker и перезапустите worker.
Войдите в Web UI и убедитесь, что число ACTIVE WORKERS стало на один меньше. Worker с некорректным секретом не проходит аутентификацию и, следовательно, не регистрируется у координатора.
Остановите кластер Trino, верните прежнее значение на worker и перезапустите кластер.
Убедитесь, что число ACTIVE WORKERS равно числу узлов, настроенных с вашим общим секретом.

Настройка внутреннего TLS#

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

Можно настроить координатор и все worker так, чтобы они шифровали весь обмен между собой через TLS. Каждый узел в кластере должен быть настроен. Узлы, которые не настроены или настроены неверно, не смогут взаимодействовать с другими узлами кластера.

В типичных развертываниях следует включать TLS directly on the coordinator для полностью зашифрованного доступа к кластеру со стороны клиентских инструментов.

Включите TLS для внутренней коммуникации следующей конфигурацией, идентичной на всех узлах кластера.

Настройте общий секрет для внутренней коммуникации, как описано в предыдущем разделе.
Включите автоматическое создание сертификатов и настройку доверия в etc/config.properties:
```
internal-communication.https.required=true
```
Измените URI службы discovery, чтобы использовать HTTPS, и укажите IP-адрес координатора в etc/config.properties:
```
discovery.uri=https://<coordinator ip address>:<https port>
```
Обратите внимание, что использование hostnames или fully qualified domain names для URI не поддерживается. Автоматическое создание сертификатов для внутреннего TLS поддерживает только IP-адреса.

Включите HTTPS endpoint на всех worker.

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

Перезапустите все узлы.

Сертификаты создаются автоматически и используются для защиты всего обмена внутри кластера с помощью TLS.

Производительность при включенном SSL/TLS#

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

Для запросов, которые не требуют передачи большого объема данных между узлами Trino, например SELECT count(*) FROM table, влияние на производительность незначительно.

Однако для CPU-intensive запросов, которые требуют передачи значительного объема данных между узлами (например, distributed joins, aggregations и window functions, требующих repartitioning), влияние на производительность может быть существенным. Замедление может варьироваться от 10% до даже 100%+ в зависимости от сетевого трафика и загрузки CPU.

Note

По умолчанию внутренняя коммуникация при включенном SSL/TLS использует HTTP/2 для повышения масштабируемости. Вы можете отключить эту возможность через internal-communication.http2.enabled=false.

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

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

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

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

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

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