В проде подход «включил и готово» почти никогда не работает. Для автономного узла техническая последовательность короткая: включить auth, перезапустить Manticore, создать администратора и обновить клиентов. В топологии с распределёнными таблицами или репликационными кластерами нужна дополнительная подготовка, потому что узлам тоже приходится аутентифицироваться друг у друга.

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

Этот чек‑лист написан для пользователей, которые планируют включить аутентификацию и хотят сделать это максимально безопасно для текущей системы. Помните, что аутентификация отключена, пока вы не настроите auth; после переключения клиенты, которые по‑прежнему не передают учётные данные будут получать отказ.

Выберите процедуру по топологии:

Этап 1. Инвентаризация перед любыми изменениями

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

Что обычно стоит проверить:

• поисковые фронтенды приложений

• воркеры, загружающие данные

• cron‑задачи

• дашборды и BI‑инструменты

• инструменты поддержки и администрирования

• скрипты изменения/обновления схемы

• скрипты резервного копирования и обслуживания

• локальные скрипты, которые запускаются вручную

Для каждого клиента запишите примерно следующее:

Затем уточните базовые параметры развёртывания:

• Это автономный узел, топология с распределёнными таблицами, репликационный кластер или их сочетание?

• Вы работаете в RT‑режиме или в plain‑режиме?

• В plain‑режиме — где должен находиться файл аутентификации?

• Настроен ли pid_file в конфиге? Он нужен для инициализации.

• Все ли участвующие узлы поддерживают один и тот же протокол аутентификации?

• Будут ли SQL‑клиенты использовать SSL, а HTTP‑клиенты — HTTPS, когда учётные данные передаются по сети?

• Где будут безопасно храниться учётные данные, включая временные Bearer‑токены?

• Кому разрешено видеть пароль первого администратора?

Если используется репликация, запишите имя каждого кластера и значение его user из <data_dir>/manticore.json на каждом узле. Перед репетицией и ещё раз перед переключением в продакшене сделайте резервные копии каталога данных, конфигурации и существующего хранилища аутентификации.

Не пропускайте вопросы об учётных данных. CREATE USER возвращает Bearer‑токен в открытом виде; TOKEN генерирует новый токен для указанного пользователя. SHOW TOKEN позже показывает сохранённый хеш токена, а не сам токен в открытом виде. Если токен в открытом виде потерян, смените его командой TOKEN и обновите токен в вашем приложении.

Этап 2. Задание пользователей с минимальными правами

Создавайте пользователей под задачи, а не под догадки о том, что может пригодиться потом.

Используйте небольшую матрицу вроде такой:

Держите в уме, что admin — это узкое право. Оно всего лишь даёт управлять состоянием аутентификации и авторизации, но не подразумевает read, write, schema или replication.

Это важно, так как человеку, который управляет учётными данными, не обязательно читать бизнес‑данные. Сервису, который ищет товары, не нужно записывать документы. Задаче миграции не нужно управлять пользователями.

Сразу спланируйте и проверки на запрет. Для каждого создаваемого пользователя выберите хотя бы одно действие, которое ему должно быть разрешено, и одно — которое должно быть запрещено.

Примеры:

• app_read может искать по products.

• app_read не может вставлять данные в products.

• app_ingest может писать в products.

• app_ingest не может управлять аутентификацией.

• schema_job может менять схему products.

• schema_job не может читать таблицы, пока вы не выдадите read.

Этап 3. Тестирование в staging

Используйте staging‑окружение, чтобы заранее отработать последовательность действий, запланированную для продакшена.

В RT‑режиме:

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

Чтобы явно отключить аутентификацию в RT‑режиме:

searchd {
    data_dir = /var/lib/manticore
    auth = 0
    ...
}

В plain‑режиме:

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

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

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

Запустите searchd, затем создайте первого администратора:

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

Для настройки через скрипт:

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

⚠️ Предупреждение: команда выше содержит пароль в открытом виде. В автоматизации продакшена передавайте три строки на стандартный ввод из системы управления секретами.

Команда создаёт первого администратора со всеми правами, включая replication; дополнительных прав не нужно. Bearer‑токен она не возвращает. Если администратору нужен доступ через HTTP Bearer, подключитесь под этим пользователем и выполните TOKEN либо используйте HTTP‑эндпоинт POST /token.

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

Далее создайте пользователей для staging исходя из ваших заметок с прошлых этапов. Например:

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

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

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

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

Сохраните возвращённые Bearer‑токены в безопасном хранилище. Помните: токены в открытом виде нельзя оставлять в логах, истории команд или незащищённых файлах. Если нужно сменить какой‑то из них, используйте:

TOKEN 'app_read';

SHOW TOKEN не позволяет восстановить токен в открытом виде:

SHOW TOKEN FOR 'app_read';

Просмотрите пользователей и права:

SHOW USERS;
SHOW PERMISSIONS;
SHOW PERMISSIONS FOR 'app_read';

Выполните один тест на разрешение и один на запрет доступа для каждого пользователя. Для пользователя с доступом только на чтение:

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

Затем проверьте ситуацию, когда прав не хватает:

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 при нехватке прав вернётся ERROR 1045 с сообщением об отказе в доступе.

SQL‑клиенты должны подключаться с именем пользователя и паролем Manticore Search. Протокол SQL/MySQL в Manticore поддерживает mysql_native_password.

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

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

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

HTTP‑схемы аутентификации (Basic, Bearer) нечувствительны к регистру; имена пользователей — чувствительны.

Если во время обслуживания вы правите файл аутентификации в обход демона, перезагрузите его:

RELOAD AUTH;

Этап 4. Чек‑лист внедрения в продакшен

Используйте этот чек‑лист для любого развёртывания, а затем следуйте процедуре для своей топологии.

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

• Отдельно сохраните резервные копии manticore.json и существующего хранилища аутентификации.

• Убедитесь, что существующие сетевые меры защиты продолжают действовать.

• Убедитесь, что pid_file задан в конфиге.

• Уточните, где будет создан или откуда будет загружен файл аутентификации.

• Убедитесь, что хранилище для паролей и токенов готово.

• Убедитесь, что на всех участвующих узлах установлена совместимая версия Manticore.

• Отрепетируйте в staging ту же топологию и порядок перезапуска.

• Подготовьте единое хранилище аутентификации для пользователей, общих между узлами.

• Выберите ниже процедуру для автономного, распределённого или репликационного сценария.

• Включайте аутентификацию в заранее запланированное технологическое окно.

• После включения auth ожидайте отказов от клиентов без учётных данных.

• Сразу после выдачи сохраняйте токены в защищённом хранилище секретов. Не храните токены в открытом виде ни в файлах, ни в истории команд, ни в логах.

• Обновите SQL‑подключения, чтобы они передавали имена пользователей и пароли.

• Обновите HTTP‑подключения, чтобы они использовали Basic‑аутентификацию или Bearer‑токены.

• Выполните тесты на разрешение и запрет доступа из staging.

• Проверьте внутренние межузловые операции, если в развёртывании есть удалённые агенты или репликация.

• Проверьте журнал аутентификации.

• Проведите стресс‑тестирование приложения, охватывающее поиск, загрузку данных, дашборды и скрипты обслуживания.

• Смените любые временные учётные данные, использованные при внедрении.

• Не используйте учётные данные первого администратора в обычной работе приложений.

Автономный узел

Для автономного узла достаточно выполнить обычную последовательность инициализации:

1. Корректно остановите Manticore и сделайте окончательную резервную копию.

2. Настройте auth и запустите searchd.

3. Создайте первого администратора командой searchd --config <path> --auth.

4. Создайте пользователей для продакшена и выдайте им права.

5. Обновите клиентов и выполните запланированные тесты на разрешение и запрет.

6. Убедитесь, что существующие таблицы и известные строки доступны.

Распределённые таблицы и удалённые агенты

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

Для нового внедрения в распределённой топологии:

1. Один раз создайте общих пользователей в изолированном демоне инициализации из этапа 3.

2. Остановите затронутые агенты и master‑узлы для согласованного переключения.

3. Настройте auth и разместите одно и то же хранилище аутентификации на каждом участвующем узле. Не меняйте владельца файлов и не ослабляйте права доступа; затем сравните контрольные суммы.

4. Сначала запустите удалённые агенты, затем master‑узлы, которые обращаются к ним.

5. Проверьте прямой аутентифицированный запрос на каждом агенте, затем такой же распределённый запрос через master.

6. Создавайте локальных пользователей узла только после того, как общий трафик заработает, и синхронизируйте данные общих пользователей при изменении паролей, токенов или прав.

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

Существующий кластер репликации

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

Используйте такой порядок:

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

   ALTER CLUSTER products UPDATE user 'cluster_repl';
   

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

   Проверьте, что <data_dir>/manticore.json каждого узла теперь содержит для кластера "user": "cluster_repl". Если узел обслуживает несколько кластеров, обновите каждый так, чтобы указанный пользователь существовал в новом хранилище аутентификации, либо до переключения создайте всех сохранённых пользователей и выдайте им права.

2. Корректно остановите все узлы и по состоянию репликации выберите узел для безопасного запуска. После корректной остановки это обычно узел, остановленный последним: в <data_dir>/grastate.dat у него стоит safe_to_bootstrap: 1. См. Restarting a cluster.

3. В изолированном временном демоне создайте cluster_repl как первого администратора. У первого администратора уже есть все действия, включая replication, поэтому дополнительно выдавать это право не нужно. Если кластер будет использовать отдельную учётную запись с минимальными правами, создайте её один раз и выдайте replication до распространения хранилища.

4. Остановите временный демон. Настройте auth на всех реальных узлах и скопируйте на каждый в точности одно и то же сгенерированное хранилище. Ограничьте доступ к файлам и убедитесь, что они побайтно совпадают. Не запускайте реальный узел кластера, пока хранилище не размещено.

5. Перезапускайте двухузловой кластер в таком порядке:

   1. Сначала обычным образом запустите узел, который не отмечен как безопасный для запуска, и дождитесь, пока демон начнёт принимать подключения. На этом этапе состояние кластера может быть closed; не выполняйте на нём записи.

   2. Запустите узел, отмеченный как безопасный для запуска, с --new-cluster либо используйте соответствующее действие сервиса manticore_new_cluster.

   3. Дождитесь, пока этот узел сообщит cluster_products_status=primary и cluster_products_node_state=synced.

   4. Корректно остановите узел, запущенный на первом подшаге, снова запустите его обычным образом и дождитесь на нём тех же значений primary и synced. Никогда не используйте на нём --new-cluster.

   При запуске узел, отмеченный как безопасный для запуска, получает данные о сохранённом пользователе кластера с узла, запущенного на первом подшаге. Поэтому запущенный на первом подшаге узел уже должен принимать подключения. Если запускать безопасный узел в одиночку, может появиться ошибка failed to fetch donor user from any node даже при корректном хранилище аутентификации. Для кластера большего размера отрепетируйте тот же порядок в staging: используйте один из остальных узлов как источник метаданных, запустите безопасный узел, затем запускайте или перезапускайте остальные узлы обычным образом.

6. На каждом узле убедитесь, что компонент кластера в состоянии primary, локальный узел — synced, а данные до миграции доступны:

   SHOW STATUS LIKE 'cluster_products_status';
   SHOW STATUS LIKE 'cluster_products_node_state';
   SELECT COUNT(*) FROM products:existing_table;
   

   Считайте узел доступным для записи, только когда статус кластера равен primary, а состояние узла — synced.

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

   CREATE TABLE migration_control (id bigint, body text);
   INSERT INTO migration_control VALUES (1, 'post-auth control');
   ALTER CLUSTER products ADD migration_control;
   

   Убедитесь, что второй узел возвращает одну строку из products:migration_control. Если эта проверка не проходит после успешной проверки данных до миграции, исследуйте передачу таблицы, а не саму миграцию.

После восстановления кластера создайте остальных администраторов и, если нужно, отдельного пользователя репликации с минимальными правами. Меняйте имя пользователя кластера в метаданных только после того, как новый пользователь и его данные аутентификации будут видны на каждом узле:

CREATE USER 'repluser' IDENTIFIED BY '<strong-secret>';
GRANT replication ON * TO 'repluser';
ALTER CLUSTER products UPDATE user 'repluser';

Не удаляйте администратора, созданного при инициализации, пока не проверите другого администратора и окончательную учётную запись репликации.

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

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

Когда аутентификация включена, события аутентификации пишутся в отдельный журнал. Если журнал демона — /var/log/manticore/searchd.log, то журнал аутентификации — /var/log/manticore/searchd.log.auth.

Значения auth_log_level:

• disabled

• error

• warning

• info

• all

• trace

По умолчанию — info. Начните с этого, если только нет причин делать логи ещё тише или, наборот, детальнее. Используйте trace только для диагностики; в него попадает в том числе весь успешный внутренний трафик аутентификации.

Полезные команды для очистки и обслуживания:

SET PASSWORD 'NewReadPass#2026' FOR 'app_read';
REVOKE read ON 'products' FROM 'app_read';
DROP USER 'app_read';

SET PASSWORD меняет пароль, используемый для SQL/MySQL и HTTP Basic‑аутентификации. Эта команда не отзывает существующие Bearer‑токены. Чтобы сменить Bearer‑токен, создайте новый с помощью TOKEN или POST /token и обновите клиента.

Этап 5. Откат и разбор проблем

Для автономного узла восстановите прежнюю конфигурацию и сетевые ограничения, перезапустите Manticore, а при необходимости откатите настройки клиентов.

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

Для каждого репликационного кластера сохраните копию manticore.json до переключения. Если auth был включён до появления сохранённого пользователя кластера, остановите узел и сравните текущий дескриптор с резервной копией. Если корректная остановка сохранила состояние без дескриптора кластера, восстановите его из копии перед повторной попыткой. Не создавайте кластерные таблицы заново и не удаляйте их данные.

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

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

Финальная проверка

Прежде чем считать внедрение завершённым убедитесь, что:

• Использована процедура, подходящая для топологии развёртывания.

• У каждой обособленной части системы, использущей Manticore Search есть свой пользователь.

• У каждого пользователя — только те действия, которые ему нужны.

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

• Bearer‑токены хранятся в защищённом хранилище секретов; токены в открытом виде не сохраняются вне контролируемой среды.

• Команда эксплуатации знает, что SHOW TOKEN не возвращает токен в открытом виде, а показывает его хеш; для получения нового токена нужно использовать TOKEN или HTTP‑эндпоинт.

• SQL и HTTP‑клиенты обновлены.

• Ожидаемые отказы проверены.

• При необходимости протестированы распределённые запросы или операции репликации.

• Каждый перенесённый репликационный кластер находится в состоянии synced, а его прежние данные доступны на каждом узле.

• Логи аутентификации доступны для просмотра.

• Процедура отката понятная и описана.

Желаем вам лёгкого внедрение аутентификации и авторизации!