Авторизация: file-based access control, Ranger, OPA
В прошлом уроке кластер научился отвечать на вопрос «кто ты» — аутентификация установила личность клиента. Теперь — второй вопрос: «что тебе можно». Установленному пользователю нужно разрешить читать одни таблицы и запретить другие, дать или не дать создавать схемы, ограничить доступ к каталогам. Это и есть авторизация — access control.
Trino не навязывает один способ авторизации. Есть встроенный system access control, есть file-based правила, есть интеграция с Apache Ranger и с Open Policy Agent. Этот урок разбирает все варианты и показывает, когда какой выбрать.
System access control: точка решения
Авторизацию в Trino выполняет компонент system access control. Каждый раз, когда запрос пытается что-то сделать — прочитать таблицу, создать схему, обратиться к каталогу, — координатор спрашивает system access control: «пользователю X можно это действие?». Ответ да или нет определяет, продолжится операция или будет отклонена.
System access control — это интерфейс с несколькими реализациями. Какая реализация подключена, такая политика и действует. Выбор реализации — и есть выбор модели авторизации кластера.
Встроенный system access control
Из коробки Trino предлагает встроенный system access control с тремя базовыми режимами:
| Режим | Что делает |
|---|---|
ALLOW_ALL | разрешает всё всем — авторизации фактически нет |
READ_ONLY | разрешает только чтение; любые операции записи и изменения запрещены |
FILE | решения по правилам из конфигурационного файла (file-based access control) |
ALLOW_ALL — режим по умолчанию в простейшей установке; для продакшена он непригоден, потому что не ограничивает никого. READ_ONLY — грубый, но иногда полезный режим: кластер только для аналитики-чтения, никакого DML и DDL. А вот FILE — это уже настоящая, гранулярная авторизация.
ALLOW_ALL означает отсутствие авторизации: любой аутентифицированный пользователь может всё. Это приемлемо для локального эксперимента, но недопустимо для продакшена. Прод-кластер обязан иметь осмысленный access control — как минимум FILE, а в зрелых окружениях Ranger или OPA.
File-based access control
File-based access control — режим FILE встроенного system access control — задаёт правила доступа в конфигурационном файле, обычно JSON.
Файл описывает набор правил: какие пользователи к каким каталогам, схемам и таблицам и с каким уровнем доступа допущены. Правила сопоставляются с действием запроса, и решение выносится по совпавшему правилу. Можно разрешить пользователю analyst только чтение каталога iceberg, дать команде etl полный доступ к определённым схемам, закрыть всё остальное.
Подключается через свойство в etc/access-control.properties:
# etc/access-control.properties
access-control.name=file
security.config-file=etc/rules.jsonСильная сторона file-based — простота и автономность: правила прямо в файле, никаких внешних систем, всё видно в одном месте, легко версионировать в git. Слабая сторона — масштабируемость управления: на сотни пользователей, десятки команд и тысячи таблиц редактирование одного JSON вручную становится громоздким и хрупким, а централизованного аудита изменений нет.
Поэтому file-based access control хорош для небольших и средних установок и для команд, которым достаточно правил «в коде». Для крупных корпоративных окружений с централизованным управлением доступом существуют другие варианты — Ranger и OPA.
Apache Ranger plugin
Apache Ranger — отдельный продукт, платформа централизованного управления безопасностью данных, распространённая в enterprise-окружениях (исторически — мир Hadoop). У Trino есть plugin для интеграции с Ranger.
Идея: политики доступа задаются и хранятся в Ranger, в его собственном UI и репозитории политик. Trino через plugin обращается к Ranger за решениями по авторизации. Кластер Trino перестаёт быть владельцем политик — он становится одним из их потребителей.
Что это даёт. Ranger управляет доступом сразу ко многим системам — не только к Trino, но и к другим компонентам data-платформы. Политики, аудит доступа, администрирование — централизованы в одном месте. Для организации с большим парком data-систем это означает единую точку управления безопасностью вместо разрозненных конфигов в каждой системе.
Open Policy Agent (OPA)
Open Policy Agent (OPA) — ещё один способ внешней авторизации, по духу более «облачно-нативный». OPA — это универсальный движок политик: политики пишутся на специальном декларативном языке политик, а приложения спрашивают OPA «можно ли это действие» и получают вердикт.
У Trino есть OPA access control. Механика та же, что с Ranger по сути: Trino делегирует решение об авторизации внешнему движку — здесь OPA. Координатор отправляет OPA контекст (кто пользователь, что за действие, над каким объектом), OPA применяет политики и возвращает «разрешено» или «отклонено».
Чем OPA отличается по подходу. OPA — стандартный, не привязанный к data-миру движок политик: одним и тем же OPA организация авторизует доступ в Kubernetes, в микросервисах, в API — и в Trino заодно. Политики как код на едином языке политик, единый движок для всей инфраструктуры. Это близко командам с GitOps-культурой и желанием держать всю авторизацию в одном стиле.
| Вариант авторизации | Где живут политики | Когда выбирать |
|---|---|---|
ALLOW_ALL | нигде, доступ открыт | только локальный эксперимент |
READ_ONLY | встроено | кластер строго для чтения |
File-based (FILE) | JSON-файл на кластере | малые и средние установки, правила «в коде» |
| Apache Ranger plugin | в Ranger | enterprise, централизация по парку data-систем |
| Open Policy Agent | в OPA, на языке политик | cloud-native, единый движок политик для всей инфраструктуры |
Как выбрать модель авторизации
Выбор опирается на масштаб и контекст организации:
- Локальный эксперимент, песочница —
ALLOW_ALLсойдёт, но это не продакшен. - Кластер строго для аналитики-чтения —
READ_ONLYгрубо отрезает любую запись. - Малая или средняя установка, хочется правила в git — file-based (
FILE). Просто, автономно, прозрачно. - Enterprise с большим парком data-систем, нужна централизация и аудит — Apache Ranger plugin: единое управление доступом ко многим системам.
- Cloud-native окружение, культура policy-as-code — Open Policy Agent: один движок политик на Kubernetes, микросервисы и Trino разом.
Общий принцип — чем крупнее окружение и чем важнее централизованный аудит, тем сильнее выбор смещается от file-based к Ranger или OPA. А ALLOW_ALL в продакшене недопустим при любом масштабе.
Аутентификация и авторизация — два независимых выбора. Можно сочетать любой механизм аутентификации из прошлого урока с любой моделью авторизации из этого: например, OAUTH2 для аутентификации плюс OPA для авторизации, или LDAP плюс Ranger. Сначала кластер устанавливает «кто ты» (аутентификация), затем — «что тебе можно» (авторизация); это разные слои, и настраиваются они порознь.
Попробуй сам
Поэкспериментируй с file-based access control на тестовом Trino.
- Подними Trino и убедись, что по умолчанию доступ ничем не ограничен (
ALLOW_ALL): любой запрос проходит. - Включи file-based access control: создай JSON-файл правил, дай некоему пользователю только чтение одного каталога (например,
tpch), пропишиaccess-control.name=fileи путь к файлу вetc/access-control.properties. Перезапусти Trino. - Проверь правила в деле: под разрешённым пользователем
SELECTизtpchпроходит, а попытка записи или обращения к закрытому каталогу отклоняется с ошибкой доступа. Прочитай тексты ошибок. - Поразмышляй: на сколько примерно пользователей и таблиц редактировать этот JSON вручную ещё комфортно, и в какой момент окружения ты бы перешёл на Ranger или OPA и почему.
Цель — увидеть, что авторизация проверяет каждое действие, и прочувствовать, где проходит граница между file-based и централизованными моделями.