Минимальный набор разрешений в типовых сценариях
В этом разделе приведён список минимально необходимых разрешений для следующих типовых сценариев работы с Tarantool DB:
Полный список системных спейсов и описание того, зачем нужен доступ к ним, приведены в разделе Системные спейсы.
Начиная с версии crud 1.6.0 (crud-ee 1.7.3) операции с данными выполняются с правами пользователя, от имени которого инициирован запрос на роутере.
CRUD передает на хранилище (storage) имя пользователя, который инициировал на роутере. Внутренний вызов выполняется от имени служебного пользователя vshard, после чего CRUD переключается на переданного пользователя и выполняет операцию с его правами. Подробнее о CRUD-операциях можно прочитать в соответствующем разделе справочника.
Выдавать прикладному пользователю право execute на universe не рекомендуется, так как оно позволяет выполнять произвольный Lua-код и существенно расширяет полномочия пользователя.
Вместо этого следует выдавать права на выполнение (execute) точечно — только на необходимые методы crud.*, которые вызываются через lua_call.
На роутере зарегистрируйте только необходимые функции CRUD и выдайте прикладному пользователю право на их вызов.
В YAML-конфигурации кластера права для пользователя можно задать в секции credentials.users.<user_name>:
credentials:users:db_user:password: 'secret'privileges:- permissions: [execute]lua_call:- crud.select- crud.get- crud.insert- crud.replace- crud.update- crud.upsert- crud.delete
Минимальный набор прав для экземпляра хранилища зависит от используемой функциональности и версии CRUD:
-
Для чтения и записи данных пользователю требуются права на чтение и запись в пользовательские спейсы, например в спейс
bands:box.schema.user.grant('db_user', 'read,write', 'space', 'bands') -
Если в кластере используется архивация данных через модуль
cooler, дополнительно требуются права на чтение системного спейса_cooler:box.schema.user.grant('db_user', 'read', 'space', '_cooler') -
Для маршрутизации запросов требуется доступ к системным спейсам:
- доступ на чтение (
read) к_bucket— чтение карты сегментов для маршрутизации запросов и проверки принадлежности сегмента. Начиная с CRUD 1.7.0 требуется для операций на хранилище;bucket_ref/unrefдля проверки состояния и принадлежности сегмента; - при использовании DDL-метаданных требуется
readна_ddl_sharding_keyи_ddl_sharding_func.
- доступ на чтение (
-
Внутренние вызовы vshard/CRUD на экземпляр хранилища. В некоторых конфигурациях (в частности, при ручной настройке прав) для выполнения внутренних вызовов на экземпляр хранилища может потребоваться право
executeна набор служебных функцийvshard.storage.*. Не рекомендуется выдавать правоexecuteдля областиuniverse.
В YAML-конфигурации кластера права для пользователя можно задать в секции credentials.users.<user_name>:
credentials:users:db_user:password: 'secret'privileges:- permissions: [read]spaces: [_bucket]- permissions: [read]spaces: [_ddl_sharding_key, _ddl_sharding_func]- permissions: [read, write]spaces: [bands]
Ребалансировка сегментов выполняется модулем шардирования vshard и подразумевает миграцию сегментов — перенос
сегментов с более нагруженных шардов на менее нагруженные.
Процесс ребалансировки запускает не пользователь Tarantool DB, а сам кластер — через
служебного пользователя для работы шардирования.
Такой пользователь указывается в конфигурации кластера и имеет встроенную системную роль sharding, которая предоставляет необходимый набор прав на системные спейсы.
Дополнительная настройка при этом не требуется.
Узнать больше о механизме шардирования и ребалансировке, а также пользователе с ролью sharding можно в разделах Шардирование и Пользователь для работы шардирования
соответственно.
Пример создания пользователя шардирования в YAML-конфигурации:
credentials:users:#...storage:password: 'sharding_password'roles: [sharding]
Здесь:
storage: пользователь для работы с модулем шардирования. Может иметь любое имя, в примере используетсяstorage;password: пароль пользователя;roles: sharding: системная роль, назначенная пользователю. Такая роль определяет разрешенные действия для пользователя в кластере.
Указать, какого пользователя использовать для выполнения ребалансировки, нужно в YAML-конфигурации в секции iproto.advertise.sharding.login:
iproto:advertise:sharding:login: storage