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

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

Аутентификация отключена, если не настроен параметр [auth](../Server_settings/Searchd.md#auth). Когда она включена, запросы без действительных учетных данных отклоняются.

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

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

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

В [режиме RT](../Read_this_first.md#Real-time-mode-vs-plain-mode) включите аутентификацию с помощью `auth = 1`. Manticore хранит данные аутентификации в `auth.json` в [data_dir](../Server_settings/Searchd.md#data_dir). Используйте `auth = 0` или не указывайте параметр, чтобы отключить аутентификацию.

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

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

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

В [обычном режиме](../Read_this_first.md#Real-time-mode-vs-plain-mode) задайте для `auth` путь к файлу аутентификации:

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

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

## Создание первого администратора

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

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

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

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

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

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

## Подключение с аутентификацией

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

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

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

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

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

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

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

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

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

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

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

## Пользователи и токены

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

```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-токен для нового пользователя:

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

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

```sql
TOKEN 'api_user';
TOKEN;
```

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

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

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

```sql
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` и `*`.

```sql
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` создает явное правило запрета. Любое совпадающее правило запрета переопределяет совпадающие правила разрешения, включая более специфичные правила разрешения.

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

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

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

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

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

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

```sql
REVOKE read ON 'private_logs' FROM 'analyst';
```

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

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

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

## Просмотр данных аутентификации

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

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

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

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

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

```sql
RELOAD AUTH;
```

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

## Политика паролей

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

* [auth_password_policy](../Server_settings/Searchd.md#auth_password_policy), значение `LOW` или `MEDIUM`.
* [auth_password_min_length](../Server_settings/Searchd.md#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](../Server_settings/Searchd.md#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` как конфиденциальные эксплуатационные данные: ограничьте доступ, обеспечьте безопасное хранение и пересылку журналов и удаляйте такие данные перед публикацией логов.

## Распределенные удаленные агенты

Когда аутентификация включена, запросы [распределенной таблицы](../Creating_a_table/Creating_a_distributed_table/Creating_a_distributed_table.md) к удаленным [agent](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent) аутентифицируются как текущий пользователь сеанса. Удаленный демон должен иметь того же пользователя с совпадающими сохраненными данными аутентификации, и у этого пользователя должно быть нужное право на удаленной целевой таблице.

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

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

## Кластеры репликации

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

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

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

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

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

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

```sql
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 и не является клиентским протоколом.
