FLUSH HOSTNAMES

Команда FLUSH HOSTNAMES используется для обновления IP-адресов, связанных с именами хостов агентов. Если вы хотите всегда запрашивать DNS для получения IP-адреса имени хоста, вы можете использовать директиву hostname_lookup.

mysql> FLUSH HOSTNAMES;
Query OK, 5 rows affected (0.01 sec)

Во многих случаях может потребоваться зашифровать трафик между клиентом и сервером. Для этого можно указать, что сервер должен использовать протокол HTTPS вместо HTTP.

ssl_ca = ca-cert.pem
ssl_cert = server-cert.pem
ssl_key = server-key.pem

ssl_cert = server-cert.pem
ssl_key = server-key.pem

Эти шаги помогут вам сгенерировать SSL-сертификаты с помощью инструмента 'openssl'.

Сервер может использовать Центр сертификации для проверки подписи сертификатов, но также может работать только с приватным ключом и сертификатом (без сертификата CA).

openssl genrsa 2048 > ca-key.pem

Чтобы сгенерировать самоподписанный CA (корневой) сертификат из приватного ключа (обязательно заполните хотя бы "Common Name"), используйте следующую команду:

openssl req -new -x509 -nodes -days 365 -key ca-key.pem -out ca-cert.pem

Сервер использует сертификат сервера для защиты связи с клиентом. Чтобы сгенерировать запрос на сертификат и приватный ключ сервера (убедитесь, что вы заполнили хотя бы "Common Name" и что он отличается от общего имени корневого сертификата), выполните следующие команды:

openssl req -newkey rsa:2048 -days 365 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

После завершения вы можете проверить, что файлы ключа и сертификата были сгенерированы правильно, выполнив:

openssl verify -CAfile ca-cert.pem server-cert.pem

При наличии корректной SSL-конфигурации доступны следующие возможности:

• Вы можете подключиться к мультипротокольному порту (когда тип слушателя не указан) по HTTPS и выполнять запросы. Как запрос, так и ответ будут зашифрованы по SSL.
• Вы можете подключиться к выделенному HTTPS-порту по HTTP и выполнять запросы. Соединение будет защищено (попытка подключиться к этому порту по обычному HTTP будет отклонена с кодом ошибки 400).
• Вы можете подключиться к MySQL-порту с помощью MySQL-клиента, используя защищённое соединение. Сессия будет защищена. Обратите внимание, что клиент mysql в Linux по умолчанию пытается использовать SSL, поэтому типичное подключение к Manticore с корректной SSL-конфигурацией, скорее всего, будет защищённым. Вы можете проверить это, выполнив SQL-команду 'status' после подключения.

Если ваша SSL-конфигурация по какой-либо причине недействительна (что демон определяет по факту невозможности установить защищённое соединение), помимо неверной конфигурации могут быть и другие причины, например, невозможность загрузить соответствующую SSL-библиотеку вообще. В этом случае следующие вещи не будут работать или будут работать в незащищённом режиме:

• Вы не можете подключиться к мультипротокольному порту по HTTPS. Соединение будет разорвано.
• Вы не можете подключиться к выделенному порту https. HTTPS-соединения будут разорваны.
• Подключение к порту mysql через MySQL-клиент не будет поддерживать защиту SSL. Если клиент требует SSL, соединение завершится ошибкой. Если SSL не требуется, будет использоваться обычное MySQL-соединение или сжатое соединение.

• Соединения по бинарному API (например, соединения от старых клиентов или междемонная связь master-agent) не защищены.
• SSL для репликации необходимо настраивать отдельно. Однако, поскольку этап SST репликации выполняется через соединение бинарного API, он также не защищён.
• Вы по-прежнему можете использовать любые внешние прокси (например, SSH-туннелирование) для защиты своих соединений.

Manticore может требовать, чтобы пользователи проходили аутентификацию перед использованием SQL через протокол MySQL, HTTP/HTTPS-эндпоинты и операции, связанные с репликацией. Аутентификация определяет пользователя. Авторизация проверяет, разрешено ли этому пользователю выполнять действие над целевым объектом.

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

Для аутентификации требуется сборка Manticore с поддержкой SSL. Используйте SSL или HTTPS, когда передаете пароли или bearer-токены по сети.

Параметр auth задается в секции searchd.

В режиме RT включите аутентификацию с помощью auth = 1. Manticore хранит данные аутентификации в auth.json в data_dir. Используйте auth = 0 или не указывайте параметр, чтобы отключить аутентификацию.

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

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

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

В обычном режиме задайте для auth путь к файлу аутентификации:

searchd {
    auth = /path/to/auth.json
}

Когда аутентификация включена, Manticore создает файл аутентификации, если его нет. До первого bootstrap допустимы отсутствие хранилища или пустое хранилище, включая файл нулевого размера, файл, состоящий только из пробелов, пустой JSON-объект или пустые массивы пользователей и прав. Полный JSON аутентификации записывается после bootstrap. Если файл аутентификации уже существует, Manticore проверяет его при запуске и отказывается стартовать, если файл неверный, недоступен для чтения или доступен для чтения группой либо всеми пользователями.

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

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

Для неинтерактивной настройки передайте имя администратора, пароль и подтверждение пароля в stdin:

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

Команда bootstrap требует запущенного демона и настроенного pid_file. Она проверяет, что хранилище аутентификации отсутствует или пусто, принимает пустой JSON-объект или пустые массивы пользователей и прав, отклоняет непустое существующее хранилище аутентификации, создает первого администратора, выдает этому пользователю все действия и просит запущенный демон перечитать данные аутентификации.

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

Для SQL через протокол MySQL подключайтесь, используя имя пользователя и пароль Manticore:

MYSQL_PWD=StrongPass#2026 mysql -h0 -P9306 -uadmin

Протокол MySQL поддерживает только аутентификацию mysql_native_password.

Для HTTP/HTTPS используйте либо HTTP Basic-аутентификацию:

curl -u admin:StrongPass#2026 http://127.0.0.1:9308/sql -d "query=SELECT 1"

либо bearer-токен:

curl -H "Authorization: Bearer 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" http://127.0.0.1:9308/sql -d "query=SELECT 1"

Чтобы создать или обновить bearer-токен для аутентифицированного HTTP-пользователя:

curl -u admin:StrongPass#2026 -X POST http://127.0.0.1:9308/token -d "{}"

Эндпоинт один раз возвращает сырой токен. Храните его безопасно.

Имена HTTP-заголовков, а также схемы Basic и Bearer принимаются без учета регистра. Имена пользователей чувствительны к регистру: app_user и App_User - это разные пользователи.

После того как создан первый администратор, управляйте пользователями с помощью SQL-команд.

CREATE USER 'app_read' IDENTIFIED BY 'ReadPass#2026';
DROP USER 'app_read';
SET PASSWORD 'NewReadPass#2026' FOR 'app_read';
SET PASSWORD 'NewOwnPass#2026';

CREATE USER возвращает сырой bearer-токен для нового пользователя:

CREATE USER 'api_user' IDENTIFIED BY 'ApiPass#2026';

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

TOKEN 'api_user';
TOKEN;

TOKEN 'api_user' создает или обновляет токен для указанного пользователя и требует права admin, если только целью не является текущий пользователь. TOKEN без указания пользователя создает или обновляет токен текущего пользователя.

SET PASSWORD меняет только аутентификацию SQL/MySQL и HTTP Basic. Она не обновляет и не отзывает существующие bearer-токены. Чтобы сделать bearer-токен недействительным, выполните TOKEN или TOKEN '<user>', чтобы обновить его.

SHOW TOKEN показывает сохраненный хеш токена, а не сырой bearer-токен:

SHOW TOKEN;
SHOW TOKEN FOR 'api_user';

Права объединяют действие, цель и правило разрешения или запрета.

Поддерживаются следующие действия:

• read - читать данные из таблиц и выполнять операции с таблицами только на чтение.
• write - записывать или удалять данные таблиц.
• schema - создавать, изменять, удалять, импортировать, перечитывать или иным образом управлять схемами таблиц и серверными метаданными.
• replication - выполнять операции кластера репликации.
• admin - управлять пользователями, токенами, правами и данными аутентификации.

Команды, которые только проверяют схемы таблиц или списки таблиц, такие как DESCRIBE, SHOW TABLES, SHOW CREATE TABLE, SHOW TABLE STATUS и SHOW TABLE SETTINGS, требуют read, а не schema.

Отсутствие права означает запрет по умолчанию. Действие admin должно быть адресовано * и не подразумевает read, write, schema или replication; при необходимости выдавайте эти права явно.

Цели - это обычные имена или шаблоны. Типичные примеры: products, logs_*, posts и *.

GRANT read ON 'products' TO 'app_read';
GRANT read ON 'logs_*' TO 'analytics';
GRANT write ON 'products' TO 'ingest';
GRANT schema ON * TO 'maintainer';
GRANT admin ON * TO 'security_admin';
REVOKE read ON 'products' FROM 'app_read';

Когда несколько правил прав могут соответствовать одному и тому же запросу, Manticore разрешает их по действию, цели и значению allow или deny.

Правила сопоставляются только для запрошенного действия. Например, право на admin не удовлетворяет read, write, schema или replication.

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

WITH ALLOW 0 создает явное правило запрета. Любое совпадающее правило запрета переопределяет совпадающие правила разрешения, включая более специфичные правила разрешения.

GRANT read ON * TO 'analyst';
GRANT read ON 'private_logs' TO 'analyst' WITH ALLOW 0;

В этом примере analyst может читать другие таблицы, но не может читать private_logs.

Совпавший шаблонный запрет также блокирует более специфичное разрешение:

GRANT read ON 'logs_*' TO 'auditor' WITH ALLOW 0;
GRANT read ON 'logs_public' TO 'auditor';

В этом примере auditor не может читать logs_public или любую другую таблицу, соответствующую logs_*, потому что шаблонный запрет совпадает с запросом.

REVOKE удаляет правило. Оно не создает правило запрета:

REVOKE read ON 'private_logs' FROM 'analyst';

GRANT также может сохранять значение бюджета в формате JSON:

GRANT read ON 'reports' TO 'analyst' WITH BUDGET '{"queries_per_day":10000}';

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

Используйте SQL-команды, чтобы просматривать пользователей и права:

SHOW USERS;
SHOW PERMISSIONS;
SHOW PERMISSIONS FOR 'api_user';
SHOW USAGE;
SHOW USAGE FOR 'api_user';

SHOW USAGE сейчас возвращает заглушки счетчиков использования. Эта команда предназначена для будущего учета использования и отчетов по бюджету.

Управляйте данными аутентификации с помощью SQL-команд выше. Базовое хранилище аутентификации является внутренним и не предназначено для пользовательского управления или просмотра.

Если файл аутентификации был изменен вне демона, перечитайте его с помощью:

RELOAD AUTH;

RELOAD AUTH требует права admin. Команды управления аутентификацией через SQL применяют изменения сразу; RELOAD AUTH в основном полезен для эксплуатационного обслуживания и перечитывания файлов в обычном режиме.

Проверка паролей контролируется следующими параметрами:

• auth_password_policy, значение LOW или MEDIUM.
• auth_password_min_length, по умолчанию 8.

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

Та же политика применяется к bootstrap, CREATE USER и SET PASSWORD.

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

Параметр auth_log_level управляет подробностью логирования:

• disabled - не записывать события аутентификации.
• error - записывать отказы в правах и критические сбои.
• warning - записывать ошибки и неудачные попытки аутентификации.
• info - записывать предупреждения и успешные изменения в управлении аутентификацией.
• all - записывать события info и успешные пользовательские события аутентификации.
• trace - записывать события all плюс успешную внутреннюю аутентификацию транспорта, такую как аутентификация Manticore Buddy и API между демонами.

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

По умолчанию используется info.

При info, all и trace успешный JOIN CLUSTER, который заменяет локальные данные аутентификации, записывает JSON-резервную копию предыдущих локальных данных auth в searchd.log.auth. Эта резервная копия содержит имена пользователей, соли, хеши паролей и bearer-хеши. Она не содержит паролей или bearer-токенов в открытом виде, но все равно является чувствительными учетными данными. Рассматривайте searchd.log.auth как конфиденциальные эксплуатационные данные: ограничьте доступ, обеспечьте безопасное хранение и пересылку журналов и удаляйте такие данные перед публикацией логов.

Когда аутентификация включена, запросы распределенной таблицы к удаленным agent аутентифицируются как текущий пользователь сеанса. Удаленный демон должен иметь того же пользователя с совпадающими сохраненными данными аутентификации, и у этого пользователя должно быть нужное право на удаленной целевой таблице.

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

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

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

CREATE USER 'repl_user' IDENTIFIED BY 'ReplPass#2026';
GRANT replication ON 'posts' TO 'repl_user';

CREATE CLUSTER и JOIN CLUSTER могут задавать эффективного пользователя репликации:

CREATE CLUSTER posts 'repl_user' AS user;
JOIN CLUSTER posts AT '10.12.1.35:9312' 'repl_user' AS user;

Если пользователь не указан, для этого оператора используется текущий пользователь сеанса. При успешном CREATE CLUSTER эффективный пользователь сохраняется как пользователь кластера. При успешном JOIN CLUSTER сохраненный пользователь кластера берется из метаданных донорского кластера.

Чтобы изменить сохраненного пользователя кластера:

ALTER CLUSTER posts UPDATE user 'repl_user';

Позднее операции кластера, такие как ALTER CLUSTER ... ADD, ALTER CLUSTER ... DROP, ALTER CLUSTER ... UPDATE nodes и DELETE CLUSTER, используют сохраненного пользователя кластера, а не текущего пользователя сеанса.

ПРИМЕЧАНИЕ: Когда аутентификация включена, успешный JOIN CLUSTER заменяет все локальные данные аутентификации на присоединяющемся узле данными аутентификации донорского кластера. Если уровень журнала аутентификации равен info или выше, Manticore перед заменой записывает предыдущие локальные данные auth в searchd.log.auth как JSON-резервную копию. Эта резервная копия включает соли и хеши учетных данных, поэтому держите журнал auth закрытым и удаляйте из него чувствительные данные перед публикацией. Перед присоединением убедитесь, что пользователь репликации и данные auth совпадают на всех узлах. Если JOIN CLUSTER не может получить данные пользователя-донора, проверьте пользователя репликации и совпадающие данные auth на узлах-донорах, а также проверьте searchd.log.auth на узлах-донорах на наличие сбоев аутентификации API.

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