Учётные данные

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

Ключ доступа и пользователь Picodata

Клиент S3 подписывает запросы парой из идентификатора ключа доступа и секретного ключа. Пару выдаёт администратор.

Ключ доступа S3 сопоставляется с пользователем Picodata, и права на операции S3 проверяются средствами СУБД. Отдельной системы управления доступом плагин не вводит. Из этого следует:

• ключ действителен, пока существует пользователь, которому он выдан;
• срок действия для ключа доступа не задаётся;
• одному пользователю можно выдать несколько ключей;
• запрос, подписанный неизвестным ключом, отклоняется. Запрос без подписи выполняется, только если это разрешает список управления доступом или политика бакета;
• ключ доступа S3 не даёт права входа в СУБД (см. Пароль для входа по SQL).

Выдача ключей (для администратора)

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

• через API управления или консоль: запрос POST /v2/credentials с телом {"username": "alice"} создаёт ключ и возвращает секретный ключ один раз, в ответе на этот запрос;
• для тенанта 0 — параметром s3r_api.credentials (см. Начальный список ключей);
• для тенантов, созданных после установки, — только через API управления тенанта.

Действующие ключи показывает запрос:

SELECT access_key, tenant_id, pico_user, state FROM s3r_credential;

Роли создаются миграциями плагина; см. Ролевая модель тенантов.

Начальный список ключей

Параметр s3r_api.credentials служит начальным списком ключей тенанта 0. Пользователь, указанный в pico_user, должен существовать заранее:

CREATE USER "alice" WITH PASSWORD '...' USING scram-sha256;

ALTER PLUGIN s3r 2.2.0 SET s3r_api.credentials =
  '[{"access_key":"AKIA...","secret_key":"...","pico_user":"alice"}]';

Параметр pico_user обязателен на практике

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

При каждом запуске сервиса s3r_api ключи из списка добавляются в таблицу s3r_credential. Запуск сервиса этой записи не ждёт: пока строка ключа не записана, подписанные им запросы отклоняются как запросы с неизвестным ключом доступа. Когда записаны все ключи списка, в журнале инстанса появляется строка seeded N credential(s) into s3r_credential.

Список только добавляет ключи:

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

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

Смена и отзыв ключей (для администратора)

Ключ из начального списка отзывается в двух местах

Удаление ключа из списка s3r_api.credentials ключ не отзывает: строка в таблице s3r_credential остаётся. И наоборот, ключ, отозванный через API управления, но оставшийся в списке, снова добавляется в таблицу при следующем запуске сервиса s3r_api. Отзывая ключ из начального списка, удалите его и из списка, и через API управления.

Задача	Действие
Отозвать ключ	Запрос DELETE /v2/credentials/{access_key} или консоль
Заменить секретный ключ	Запрос PUT /v2/credentials/{access_key} выдаёт ключу новый секретный ключ; прежний секретный ключ после этого не действует
Отозвать все ключи пользователя	Удалите или заблокируйте пользователя средствами SQL: ключ, выданный несуществующему пользователю, не действует

Смена ключа без перерыва в обслуживании выполняется в три шага:

1. Выдайте пользователю второй ключ.
2. Переведите приложение на новый ключ.
3. Отзовите старый ключ.

Когда изменение начинает действовать, зависит от способа:

• Запрос API управления возвращает ответ после того, как изменение ключа начало действовать на инстансе, принявшем запрос.
• Изменение, записанное в таблицу s3r_credential или _pico_user средствами SQL, каждый инстанс применяет сразу после фиксации записи у себя, обычно за миллисекунды. Поэтому запрос S3, отправленный сразу после такой записи, ещё может получить прежний ответ.

Пароль для входа по SQL (для администратора)

Пользователь, созданный через консоль или API управления, получает случайный пароль, который никому не сообщается, потому что ключ доступа S3 не даёт права входа в СУБД. Подключиться таким пользователем через psql можно только после того, как пароль задан явно.

Пароль открывает все привилегии пользователя Picodata

Пароль открывает вход от имени пользователя Picodata со всеми его ролями и привилегиями SQL. При этом ключ доступа администратор тенанта может выдать пользователю с любым именем, в том числе уже существующему: ключ в тенанте не означает, что пользователь принадлежит этому тенанту. Поэтому задать пароль может только s3r_superuser; администратор тенанта получает ответ 403.

Пароль задаётся для отдельного пользователя кнопкой «SQL password» в списке пользователей консоли или запросом к API управления:

PUT /v2/users/password?tenant_id=0
{"username": "alice", "password": "..."}

Пароль сохраняется методом scram-sha256. Только этот метод принимают одновременно psql, консоль и протокол iproto:

• метод chap-sha1 принадлежит Tarantool, и протокол PostgreSQL его отклоняет, намеренно не уточняя причину, чтобы по ответу нельзя было подбирать имена пользователей;
• метод md5 слабее.

Тот же запрос переводит на scram-sha256 пользователя, созданного ранее с другим методом.

Внешний провайдер идентификации

Пароль задаётся только там, где пароли проверяет сам кластер (auth_type: "picodata"). Если настроен внешний провайдер идентификации, пароли принадлежат ему: запрос отклоняется с кодом ProviderOwnsPasswords, а консоль не показывает кнопку.

Смена пароля записывается в журнал аудита Picodata событием change_password. Инициатором в этом событии указан служебный пользователь плагина, поэтому для полной картины событие сопоставляется с журналом обращений к API управления.

Пароль пользователя, созданного средствами SQL, меняется штатной командой Picodata:

ALTER USER "alice" WITH PASSWORD '...';