Аутентификация: PASSWORD, LDAP, OAUTH2, KERBEROS, JWT, CERTIFICATE

Trino — точка доступа к данным многих источников. Без аутентификации любой, кто дотянулся до координатора по сети, мог бы выполнять запросы. Аутентификация отвечает на вопрос «кто ты» — устанавливает личность клиента, прежде чем кластер начнёт его обслуживать.

Trino поддерживает несколько механизмов аутентификации, рассчитанных на разные корпоративные окружения. Этот урок разбирает каждый тип, показывает, как они объединяются в цепочку, и объясняет, почему почти все требуют TLS и shared secret.

Аутентификация против авторизации

Сначала — терминологическая граница, которую нельзя путать.

Аутентификация (authentication) — установление личности: «кто ты». Клиент доказывает, что он тот, за кого себя выдаёт.
Авторизация (authorization) — проверка прав: «что тебе можно». Уже установленной личности разрешается или запрещается конкретное действие — чтение таблицы, создание схемы.

Этот урок — только про аутентификацию, про «кто ты». Авторизации — «что тебе можно» — посвящён следующий урок. Сначала кластер устанавливает, кто перед ним, и лишь потом решает, что этому «кому-то» позволено.

Типы аутентификации Trino

Аутентификация настраивается свойством http-server.authentication.type в etc/config.properties. Поддерживаемые типы:

Тип	Что это	Типичное применение
`PASSWORD`	логин и пароль; проверка по файлу паролей или через LDAP	простые установки, файл паролей
`LDAP`	проверка учётных данных в LDAP/Active Directory	корпоративный каталог пользователей
`OAUTH2`	OAuth 2.0 / OpenID Connect через внешний провайдер	SSO, современные identity-провайдеры
`KERBEROS`	аутентификация по протоколу Kerberos	окружения Hadoop/enterprise с Kerberos
`JWT`	проверка подписанного JSON Web Token	сервис-к-сервису, токены от внешней системы
`CERTIFICATE`	клиентский TLS-сертификат как удостоверение	mTLS, машинные клиенты
`HEADER`	личность из доверенного HTTP-заголовка	за доверенным прокси

Коротко о механике главных:

PASSWORD — клиент шлёт логин и пароль. Trino проверяет их либо по локальному файлу паролей, либо обращаясь к LDAP. Простейший вариант для начала.

LDAP — учётные данные проверяются в LDAP-каталоге (часто Active Directory). Не нужно вести пользователей в Trino — единый корпоративный каталог уже есть.

OAUTH2 — Trino делегирует аутентификацию внешнему OAuth 2.0 / OpenID Connect провайдеру. Пользователь логинится у identity-провайдера, тот выдаёт токен. Это путь к single sign-on.

KERBEROS — аутентификация по протоколу Kerberos, стандарт во многих enterprise- и Hadoop-окружениях.

JWT — клиент предъявляет подписанный JSON Web Token; Trino проверяет подпись. Удобно для сервис-к-сервису взаимодействия, когда токены выпускает внешняя система.

CERTIFICATE — удостоверением служит клиентский TLS-сертификат: клиент предъявляет сертификат при TLS-рукопожатии, и этого достаточно (взаимный TLS, mTLS).

Цепочка из нескольких механизмов

http-server.authentication.type принимает несколько типов через запятую. Это не «или одно, или другое» — это цепочка.

# etc/config.properties
# Несколько механизмов: проверяются по порядку
http-server.authentication.type=CERTIFICATE,OAUTH2,PASSWORD

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

Цепочка аутентификации: первый успех даёт доступ

CERTIFICATE

не сработал

OAUTH2

не сработал

PASSWORD

Зачем цепочка? Чтобы один кластер обслуживал разнородных клиентов. Машинные сервисы приходят с клиентскими сертификатами; живые пользователи логинятся через OAuth2; легаси-инструмент умеет только логин и пароль. Цепочка CERTIFICATE,OAUTH2,PASSWORD пускает всех троих, каждого — его родным механизмом, без отдельного кластера под каждый тип клиента.

NOTE

Порядок в цепочке имеет значение по двум причинам: проверки идут слева направо до первого успеха, и более «дешёвые» либо более строгие механизмы логично ставить раньше. Например, CERTIFICATE проверяется уже на этапе TLS-рукопожатия — естественно поставить его первым.

Почему почти всё требует TLS

Ключевое эксплуатационное правило: большинство методов аутентификации требуют TLS/HTTPS. Это не придирка, а необходимость.

Аутентификация по своей природе передаёт секреты: пароль при PASSWORD/LDAP, токен при OAUTH2/JWT, билеты Kerberos. Если соединение между клиентом и координатором — обычный HTTP без шифрования, эти секреты летят по сети открытым текстом. Любой, кто слушает трафик, перехватит пароль или токен и сможет выдать себя за легитимного пользователя. Аутентификация поверх незашифрованного канала — это иллюзия безопасности.

Поэтому Trino требует TLS как условие работы парольных и токеновых методов. В частности, OAUTH2 требует настроенного TLS на координаторе — иначе механизм просто не включится.

Аутентификация без TLS и с TLS

HTTP без TLS: секрет открытым текстом

включаем TLS/HTTPS

HTTPS с TLS: секрет зашифрован

Деталям TLS/HTTPS и управления секретами посвящён отдельный урок этого модуля. Здесь важно усвоить причинно-следственную связь: аутентификация передаёт секреты -> секреты нельзя слать открытым текстом -> значит, нужен TLS.

Shared secret для внутренней коммуникации

Есть ещё один элемент, который идёт в паре с аутентификацией, — shared secret, настраиваемый общий секрет кластера.

Аутентификация защищает периметр: проверяет внешних клиентов, приходящих на координатор. Но кластер — это ещё и внутренняя коммуникация между координатором и воркерами. Если её не защитить, появляется лазейка: злоумышленник, прикинувшись «воркером» или «координатором», мог бы вклиниться во внутренний обмен в обход внешней аутентификации.

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

# etc/config.properties — одинаковый на ВСЕХ нодах кластера
internal-communication.shared-secret=<длинная случайная строка>

WARNING

internal-communication.shared-secret должен быть одинаковым на всех нодах кластера и достаточно длинной случайной строкой. Большинство механизмов внешней аутентификации в Trino требуют, чтобы shared secret был настроен: без него безопасность кластера дырявая — внешний периметр закрыт, а внутренний обмен нот доверчиво открыт. Внешняя аутентификация и shared secret настраиваются в паре.

Как собрать аутентификацию

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

Сначала TLS. Парольные и токеновые методы требуют TLS на координаторе. Нет TLS — нет аутентификации (детали — в уроке про TLS).
Shared secret. Задай internal-communication.shared-secret, одинаковый на всех нодах, — защити внутренний обмен, не только периметр.
Выбери тип(ы) аутентификации под своих клиентов: один механизм или цепочка через запятую под разнородную клиентуру.
Настрой выбранные механизмы — файл паролей для PASSWORD, параметры каталога для LDAP, провайдера для OAUTH2 и так далее.

Получается слоёная защита: TLS шифрует канал, аутентификация устанавливает личность внешнего клиента, shared secret аутентифицирует ноды между собой. И только после того, как личность установлена, в дело вступает авторизация — следующий урок.

Попробуй сам

Настрой аутентификацию на тестовом Trino.

Подними Trino и включи PASSWORD-аутентификацию с файлом паролей: создай файл паролей, пропиши http-server.authentication.type=PASSWORD и путь к файлу. Для этого понадобится TLS — настрой самоподписанный сертификат на координаторе (детали будут в уроке про TLS, но базово этого достаточно для опыта).
Проверь: подключение Trino CLI без логина и пароля отклоняется, с верными — проходит, с неверными — отклоняется. Прочитай тексты ошибок.
Задай internal-communication.shared-secret одинаковым на всех нодах. Затем намеренно поставь на одном воркере другой secret, перезапусти его и посмотри, что воркер не может корректно участвовать в кластере.
Поразмышляй: если бы у тебя были и машинные сервисы (умеют сертификаты), и живые пользователи (умеют OAuth2), и старый BI-инструмент (умеет только пароль), какую цепочку http-server.authentication.type ты бы задал и в каком порядке?

Цель — увидеть, что аутентификация устанавливает личность, требует TLS для защиты секретов, а shared secret закрывает внутренний периметр кластера.

Проверка знанийKnowledge check

Зачем Trino позволяет задать несколько типов аутентификации через запятую, и чем shared secret отличается от внешней аутентификации клиентов?

ОтветAnswer

Несколько типов аутентификации через запятую (например, http-server.authentication.type=CERTIFICATE,OAUTH2,PASSWORD) образуют цепочку: Trino проверяет механизмы по порядку слева направо, и клиент считается аутентифицированным по первому, который сработал успешно; если ни один не подошёл — доступ отклонён. Нужна цепочка для того, чтобы один кластер обслуживал разнородных клиентов без отдельного кластера под каждый тип: машинные сервисы приходят с клиентскими сертификатами и проходят по CERTIFICATE, живые пользователи логинятся через корпоративный SSO и проходят по OAUTH2, а легаси-инструмент умеет только логин и пароль и проходит по PASSWORD — все трое обслуживаются одним кластером, каждый своим родным механизмом. Порядок значим, потому что проверки идут до первого успеха. Shared secret отличается от внешней аутентификации тем, какой рубеж он защищает. Внешняя аутентификация проверяет внешних клиентов, приходящих на координатор по сети, — устанавливает их личность на периметре кластера. Shared secret (internal-communication.shared-secret) — это общий секрет, известный всем нодам кластера, которым координатор и воркеры аутентифицируют друг друга во внутреннем взаимодействии. Без него внутренний обмен нот остался бы доверчиво открытым, и злоумышленник, прикинувшись воркером или координатором, мог бы вклиниться во внутреннюю коммуникацию в обход внешней аутентификации. Это два разных рубежа: внешняя аутентификация закрывает периметр, shared secret закрывает внутренний обмен между нодами; они настраиваются в паре, и большинство механизмов внешней аутентификации требуют, чтобы shared secret тоже был настроен.