TLS и HTTPS#

По умолчанию Trino работает без безопасности. Это позволяет подключаться к серверу, используя URL с протоколом HTTP при работе с CLI Trino, Web UI или другими клиентами.

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

Important

На этой странице рассматривается только подготовка сервера Trino для защищенных клиентских подключений извне кластера Trino к его координатору.

См. Глоссарий, чтобы уточнить незнакомые термины.

Поддерживаемые стандарты#

При настройке на использование TLS сервер Trino отвечает на клиентские подключения с использованием сертификатов TLS 1.2 и TLS 1.3. Сервер отклоняет TLS 1.1, TLS 1.0 и все сертификаты в формате SSL.

Сервер Trino не задает собственный набор поддерживаемых шифров, а использует настройки по умолчанию версии JVM. В документации Java 24 перечислены поддерживаемые наборы шифров.

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

echo "java.util.Arrays.asList(((javax.net.ssl.SSLServerSocketFactory) \
javax.net.ssl.SSLServerSocketFactory.getDefault()).getSupportedCipherSuites()).forEach(System.out::println)" | jshell -

Сервер Trino по умолчанию использует набор регулярных выражений, исключающих старые наборы шифров, не поддерживающие прямую секретность (FS).

Используйте свойство http-server.https.included-cipher, чтобы указать разделенный запятыми список шифров в порядке предпочтения. Если один из предпочтительных вариантов - шифр без FS, также необходимо установить свойство http-server.https.excluded-cipher в пустой список, чтобы переопределить исключения по умолчанию. Например:

http-server.https.included-cipher=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256
http-server.https.excluded-cipher=

Указание другого набора шифров - сложная задача, которую следует рассматривать только совместно со специалистами по безопасности вашей организации. Использование другого набора может потребовать загрузки и установки другого пакета реализации SunJCE. В некоторых юрисдикциях могут действовать экспортные ограничения на наборы шифров. См. обсуждение в документации Java, начинающееся с Customizing the Encryption Algorithm Providers.

Note

Если вы управляете прямой реализацией TLS на координаторе, отслеживайте загрузку CPU координатора Trino после включения HTTPS. Java предпочитает более ресурсоемкие по CPU наборы шифров, если ей доступен большой список шифров. Если после включения HTTPS загрузка CPU становится недопустимо высокой, можно настроить Java на использование конкретных наборов шифров, как описано в этом разделе.

Однако лучшей практикой является использование внешнего балансировщика нагрузки, как обсуждается далее.

Подходы#

Чтобы настроить Trino с поддержкой TLS, рассмотрите два альтернативных пути:

  • Использовать балансировщик нагрузки или прокси на вашей площадке или в облачной среде для терминации TLS/HTTPS. Это самый простой и настоятельно рекомендуемый вариант.

  • Защитить сам сервер Trino. Для этого потребуется получить действительный сертификат и добавить его в конфигурацию координатора Trino.

Использование балансировщика нагрузки для терминации TLS/HTTPS#

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

Когда балансировщик нагрузки принимает TLS-шифрованное соединение, он добавляет в запрос forwarded HTTP-заголовок, например X-Forwarded-Proto: https.

Это сообщает координатору Trino, что соединение нужно обработать так, как будто TLS для него уже успешно согласован. Именно поэтому для координатора за балансировщиком не нужно настраивать http-server.https.enabled=true.

Однако, чтобы включить обработку таких forwarded-заголовков, в файл свойств конфигурации сервера обязательно нужно добавить следующее:

http-server.process-forwarded=true

Больше сведений о конфигурации HTTP-сервера доступно в HTTP server properties.

На этом необходимая настройка HTTPS при использовании балансировщика нагрузки завершена. Клиентские инструменты могут обращаться к Trino по URL, предоставленному балансировщиком.

Прямая защита Trino#

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

Добавление TLS-сертификата#

Получите файл TLS-сертификата для использования с сервером Trino. Рассмотрите следующие типы сертификатов:

  • Глобально доверенные сертификаты - сертификат, которому автоматически доверяют все браузеры и клиенты. Это самый простой вариант, так как не требуется настройка клиентов. Такой сертификат можно получить у:

    • коммерческого поставщика сертификатов

    • вашего поставщика облачной инфраструктуры

    • регистратора доменных имен, например Verisign или GoDaddy

    • бесплатного сервиса генерации сертификатов, например letsencrypt.org или sslforfree.com

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

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

Самый удобный и настоятельно рекомендуемый вариант - глобально доверенный сертификат. Он может потребовать немного больше усилий в начале, но это окупается тем, что не нужно настраивать каждого клиента отдельно.

Ключи и сертификаты#

Trino может читать сертификаты и приватные ключи, закодированные в форматах PEM encoded PKCS #1, PEM encoded PKCS #8, PKCS #12 и legacy-формате Java KeyStore (JKS). Сертификаты и приватные ключи в бинарном формате, например DER, должны быть преобразованы.

Убедитесь, что вы получили сертификат, валидируемый признанным центром сертификации.

Проверка полученных сертификатов#

Перед установкой сертификата проверьте и валидируйте полученные файлы ключа и сертификата, чтобы убедиться, что они содержат корректные данные для доступа к серверу Trino. На практике это экономит много времени на отладку перед переходом к конфигурированию сервера.

Проверяйте файлы в формате PEM, как описано в Inspect PEM files.

Проверяйте хранилища PKCS # 12 и JKS, как описано в Inspect JKS files.

Недействительные сертификаты#

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

Размещение файла сертификата#

К месту хранения файла сертификата нет жестких требований, при условии что:

  • Файл доступен для чтения процессу сервера-координатора Trino.

  • Местоположение защищено от копирования или подмены злоумышленниками.

Вы можете разместить файл в каталоге etc координатора Trino, что позволит использовать относительный путь в конфигурационных файлах. Однако в этом случае придется отдельно отслеживать файл сертификата и переносить его в новый каталог etc при обновлении версии Trino.

Настройка координатора#

На координаторе добавьте следующие строки в файл свойств конфигурации, чтобы включить поддержку TLS/HTTPS на сервере.

Note

В именах свойств используется legacy-терминология keystore и truststore, даже при прямом использовании сертификатов в формате PEM.

http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=etc/clustercoord.pem

Возможные альтернативы для третьей строки:

http-server.https.keystore.path=etc/clustercoord.jks
http-server.https.keystore.path=/usr/local/certs/clustercoord.p12

Относительные пути отсчитываются от корневого каталога сервера Trino. В установке tar.gz корневой каталог находится на один уровень выше каталога etc.

Хранилища JKS всегда требуют пароль, тогда как PEM-файлы с паролями Trino не поддерживает. Для JKS добавьте в конфигурацию следующую строку:

http-server.https.keystore.key=<keystore-password>

Ключ внутри keystore может иметь собственный пароль, независимый от пароля keystore. В этом случае задайте пароль ключа с помощью свойства:

http-server.https.keymanager.password=<key-password>

Когда на координаторе Trino включен аутентификатор вместе с HTTPS, HTTP-доступ автоматически отключается для всех клиентов, включая Web UI. Хотя это не рекомендуется, можно снова включить доступ, задав:

http-server.authentication.allow-insecure-over-http=true

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

Чтобы проверить конфигурацию TLS/HTTPS, войдите в Web UI и отправьте запрос через CLI Trino.

  • Подключитесь к Web UI из браузера по URL с HTTPS, например https://trino.example.com:8443. Введите любое имя пользователя в поле Username и войдите в UI. Поле Password отключено, пока не настроена аутентификация.

  • Подключитесь через Trino CLI по URL с HTTPS, например https://trino.example.com:8443:

./trino --server https://trino.example.com:8443

Отправьте запрос для проверки соединения:

trino> SELECT 'rocks' AS trino;

trino
-------
rocks
(1 row)

Query 20220919_113804_00017_54qfi, FINISHED, 1 node
Splits: 1 total, 1 done (100.00%)
0.12 [0 rows, 0B] [0 rows/s, 0B/s]

Ограничения самоподписанных сертификатов#

Самоподписанный сертификат можно сгенерировать командами openssl, keytool или, в Linux, certtool. Самоподписанные сертификаты могут быть полезны на этапе разработки кластера только для внутреннего использования. Мы рекомендуем никогда не использовать самоподписанные сертификаты на production-сервере Trino.

Самоподписанные сертификаты никем не считаются доверенными. Обычно их создает администратор ради быстроты, потому что для них не требуется подтверждение доверия от внешней стороны.

Для использования самоподписанного сертификата при разработке кластера нужно:

  • распространить на каждый клиент локальный truststore, валидирующий сертификат

  • настроить каждый клиент на использование этого сертификата

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

Существует разница между самоподписанными и неподписанными сертификатами. Оба типа создаются одними и теми же инструментами, но неподписанные сертификаты предназначены для отправки в CA вместе с Certificate Signing Request (CSR). CA возвращает сертификат, подписанный CA и уже глобально доверенный.