Минимальный набор разрешений в типовых сценариях

В этом разделе приведён список минимально необходимых разрешений для следующих типовых сценариев работы с Tarantool DB:

• Чтение и запись данных через модуль CRUD
• Выполнение ребалансировки

Полный список системных спейсов и описание того, зачем нужен доступ к ним, приведены в разделе Системные спейсы.

Начиная с версии crud 1.6.0 (crud-ee 1.7.3) операции с данными выполняются с правами пользователя, от имени которого инициирован запрос на роутере.

CRUD передает на хранилище (storage) имя пользователя, от имени которого операция была инициирована на роутере. Внутренний вызов выполняется через служебного пользователя vshard, после чего CRUD переключается на переданного пользователя и выполняет операцию с его правами. Подробнее о CRUD-операциях в справочнике.

Не рекомендуется выдавать прикладному пользователю право execute на universe, так как оно позволяет выполнять произвольный Lua-код и существенно расширяет полномочия пользователя. Вместо этого следует выдавать execute точечно — только на необходимые методы crud.*, которые вызываются через lua_call:

 
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 требуется storage-операциям; bucket_ref/unref для проверки состояния и принадлежности бакета;
  • при использовании DDL-метаданных требуется read на _ddl_sharding_key и _ddl_sharding_func;
  • в 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/CRUD на экземпляр хранилища. В некоторых конфигурациях (в частности, на Tarantool 2.x или при ручной настройке прав) для выполнения внутренних вызовов на экземпляр хранилища может потребоваться право execute на набор служебных функций vshard.storage.*. Не рекомендуется выдавать право execute для области universe.

Ребалансировка сегментов выполняется модулем шардирования 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