Поиск нередко считают просто инфраструктурой. Но в продакшене он фактически работает как API приложения: принимает пользовательский трафик, отдаёт бизнес-данные, обслуживает дашборды и нередко стоит рядом с записями, которые не должны быть доступны каждому клиенту в сети.

В Manticore Search теперь (с релиза 27.1.5 ) есть встроенная аутентификация и авторизация — для SQL по протоколу MySQL, для HTTP/HTTPS-эндпоинтов и для операций, связанных с репликацией.

Аутентификация отвечает на вопрос «кто делает запрос?». Авторизация — «что этому пользователю разрешено делать?».

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

Что добавилось в Manticore

• Аутентификация SQL/MySQL по паролю с mysql_native_password.
• HTTP Basic-аутентификация с тем же именем пользователя и паролем.
• HTTP Bearer-токены для случаев, когда нельзя отправлять пароль в каждом запросе.
• Пермиссии на пять понятных действий: read, write, schema, replication и admin.
• Цели вроде products, logs_*, posts и *.
• SQL-команды для управления пользователями, токенами и правами.
• Лог аутентификации с уровнями disabled, error, warning, info, all и trace. По умолчанию — info.

Модель доступа специально задумана компактной. Просто создайте пользователей, назначьте им соответствующие права, обновите приложение, чтобы оно отправляли учётные данные, и убедитесь, что запрещённые операции действительно запрещены.

Включение аутентификации

Аутентификация включаемся параметром auth в секции searchd в конфиге.

Для режима RT задайте auth = 1. В этом случае Manticore будет хранить данные аутентификации в файле auth.json в каталоге data_dir.

searchd {
    data_dir = /var/lib/manticore
    auth = 1
    auth_log_level = info
}

Чтобы отключить аутентификацию в режиме RT, установите auth = 0 либо удалите директиву.

В режиме plain задайте в auth путь к файлу аутентификации:

searchd {
    auth = /var/lib/manticore/auth.json
    auth_log_level = info
}

При передаче паролей или bearer-токенов по сети обязательно используйте SSL для SQL-соединений и HTTPS для HTTP-клиентов.

Обеспечьте ограниченный доступ к файлу аутентификации: он должен быть недоступен посторонним. До первой инициализации Manticore может создать пустой файл аутентификации. После инициализации в нём хранятся данные аутентификации и хеши учётных данных.

Инициализация первого администратора

После включения auth запустите searchd. Затем создайте первого администратора, используя тот же конфигурационный файл:

searchd --config /etc/manticoresearch/manticore.conf --auth

Для автоматизированной инициализации используйте неинтерактивный режим:

printf 'admin\nStrongPass#2026\nStrongPass#2026\n' | \
  searchd --config /etc/manticoresearch/manticore.conf --auth-non-interactive

Для инициализации обязательно требуется запущенный демон. Эта команда создаёт первого администратора и выдаёт ему права на все действия.

bearer-токен при этом не выдаётся автоматически. Если администратору нужен доступ через HTTP Bearer, подключитесь под этим администратором и выполните TOKEN, либо вызовите HTTP-эндпоинт POST /token.

Создание пользователей

После инициализации администратора вы можете через его учётную запись управлять пользователями и правами через SQL-команды. Не используйте его учётную запись в приложении. Вместо этого создавайте отдельных пользователей под конкретные задачи.

Например, поисковому фронтенду, который только читает из products, нужны права read, а не write, schema, replication или admin:

CREATE USER 'app_read' IDENTIFIED BY 'ReadPass#2026';
GRANT read ON 'products' TO 'app_read';

Команда CREATE USER выводит bearer-токен нового пользователя в открытом виде. Сохраните его сразу — повторно Manticore его не покажет.

Чтобы позже создать или перевыпустить bearer-токен:

TOKEN 'app_read';

Команда TOKEN 'app_read' возвращает новый готовый к использованию токен в открытом виде. Имейте в виду, что SHOW TOKEN показывает сохранённый хеш токена, а не сам токен, который нужно отправлять в HTTP-запросе. Это полезно для проверки и аудита: можно убедиться, что токен существует или изменился после перевыпуска, не раскрывая сам секрет:

SHOW TOKEN FOR 'app_read';

SET PASSWORD меняет пароль, используемый SQL/MySQL и HTTP Basic-аутентификацией:

SET PASSWORD 'NewReadPass#2026' FOR 'app_read';

Существующие bearer-токены при этом не отзываются. Чтобы перевыпустить токен для Bearer-доступа, создайте новый через TOKEN или POST /token:

TOKEN 'app_read';

ETL-пайплайну, который загружает данные, достаточно write — более широкие права не нужны:

CREATE USER 'app_ingest' IDENTIFIED BY 'IngestPass#2026';
GRANT write ON 'products' TO 'app_ingest';

Задаче миграции схемы таблиц можно выдать schema:

CREATE USER 'schema_job' IDENTIFIED BY 'SchemaPass#2026';
GRANT schema ON 'products' TO 'schema_job';

Администратор аутентификации может получить права admin:

CREATE USER 'security_admin' IDENTIFIED BY 'AdminPass#2026';
GRANT admin ON * TO 'security_admin';

Права admin управляет только состоянием аутентификации и авторизации. Это не подразумевает read, write, schema или replication. Если этому же пользователю такие права действительно нужны, выдайте их отдельно.

Подключение через SQL и HTTP

mysql-клиенты проходят аутентификацию по имени пользователя и паролю Manticore:

MYSQL_PWD=ReadPass#2026 \
  mysql -h127.0.0.1 -P9306 -uapp_read \
  -e "SELECT * FROM products LIMIT 10"

HTTP/HTTPS-клиенты могут использовать Basic-аутентификацию:

curl -u app_read:ReadPass#2026 \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "SELECT * FROM products LIMIT 10"

Также можно использовать bearer-токен, возвращённый командами CREATE USER, TOKEN или POST /token:

curl -H "Authorization: Bearer <app_read_token>" \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "SELECT * FROM products LIMIT 10"

Схемы аутентификации Basic и Bearer нечувствительны к регистру, а имена пользователей чувствительны.

Проверка прав в обоих случаях одинакова: клиент проходит аутентификацию, Manticore определяет пользователя, и запрошенное действие сверяется с правами этого пользователя.

Тестирование после включения аутентификации

Совет: при включении доступа к Manticore не стоит останавливаться на проверке того факта, что клиент может подключиться после включения аутентификации. Неплохо бы ещё проверить и запрещённый доступ и то, как ваше приложение на это отреагирует.

Пользователь app_read должен успешно читать из products:

curl -H "Authorization: Bearer <app_read_token>" \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "SELECT * FROM products LIMIT 10"

А вот запись в products у того же пользователя проходить не должна:

curl -H "Authorization: Bearer <app_read_token>" \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "INSERT INTO products(id,title) VALUES(1,'test')"

Ошибка в данном случае — ожидаемое поведение. Если у пользователя нет необходимых пермиссий, HTTP-запрос завершится ошибкой 403 Forbidden. По SQL/MySQL Manticore возвращает ERROR 1045 с сообщением о запрете доступа.

Как проверяется, что можно, а что нельзя

Права в Manticore — это правила вида «действие + цель». Если ни одно правило не разрешает запрошенное действие над запрошенной целью, доступ запрещается.

Коротко:

• Правила сопоставляются только для запрошенного действия. admin не покрывает read, write, schema или replication.
• WITH ALLOW 0 создаёт явный запрет.
• Любой совпавший явный запрет побеждает, даже если есть более специфичное разрешающее правило.
• Если совпавшего разрешения нет, доступ запрещается.

Пример:

CREATE USER 'analyst' IDENTIFIED BY 'AnalystPass#2026';
GRANT read ON * TO 'analyst';
GRANT read ON 'private_logs' TO 'analyst' WITH ALLOW 0;

Пользователь analyst может читать остальные таблицы, но не может читать private_logs.

Запрет по маске в сочетании с точным разрешением нельзя использовать, как способ сделать исключение. Если запрет совпадает с запросом, он всё равно побеждает.

Внедрение доступа в уже работающей системе

Аутентификацию на уже работающих инстансах Manticore рекомендуется внедрять поэтапно, а не переключать всё за раз:

1. Составьте список SQL и HTTP-клиентов, которые подключаются к Manticore.
2. Выберите путь к файлу аутентификации: auth.json в data_dir в режиме RT, либо явный путь в режиме plain.
3. Включите аутентификацию на стейджинге.
4. Инициализируйте первого администратора.
5. Создайте пользователей с минимальными правами для поиска, записи, изменения схемы, репликации и администрирования аутентификации.
6. Обновите код подключения через SQL в вашем приложении, чтобы он отправлял имя пользователя и пароль.
7. Обновите код подключения через HTTP/HTTPS, чтобы он использовал Basic-аутентификацию или Bearer-токены.
8. Для каждого пользователя приложения проверьте ожидаемый успех и ожидаемый отказ.
9. Настройте подходящий уровень логирования аутентификации и убедитесь, что лог хранится безопасно вместе с остальными операционными логами.
10. Выкатывайте изменения постепенно, а после переключения перевыпустите учётные данные для большей безопасности и дополнительного теста и самообучения.

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

Кластеры репликации используют действие replication. Когда аутентификация включена, присоединение к кластеру может заменить локальные данные аутентификации данными из донорского кластера, поэтому до присоединения согласуйте данные аутентификации между узлами. Во время работы с кластером обращайтесь с логом аутентификации (по умолчанию файл searchd.log.auth) с бережностью, так как в нём могут содержаться соли и хеши учётных данных.

Полный справочник

Полный набор команд и детали эксплуатации новой фукнциональности приведены в разделе руководства — включая политику паролей, уровни лога аутентификации, SHOW USERS, SHOW PERMISSIONS, RELOAD AUTH, а также работу удалённых агентов в распределённых таблицах и кластеры репликации:

Руководство по аутентификации и авторизации

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