Ресурсная модель и права доступа
Кратко:
- Ресурсная модель и права доступа контролируются с помощью сервиса IAM и ролевой модели RBAC.
- Роль - это набор разрешений, описывающих допустимые операции над ресурсом, назначаемые пользователю.
- Роли наследуются, разрешения от родительского ресурса действуют на дочерние ресурсы.
- В Yandex Cloud используются два типа ролей: примитивные и сервисные.
- Примитивные роли предназначены для быстрой настройки и тестирования, сервисные обеспечивают более гранулярный контроль.
- Роли могут быть назначены на объекты, для которых они предназначены, или на родительский ресурс.
- Владельцы облака и участники имеют разные роли, определяющие их доступ к облачным ресурсам.
- Сервис IAM использует роль iam.serviceAccounts.user для предоставления прав на использование сервисных аккаунтов.
Ресурсная модель и права доступа
Сервис IAM используется не только для того, чтобы контролировать доступ к облачным ресурсам. С его помощью также назначают права доступа. Для этого применяют ролевую модель управления доступом — RBAC (Role Based Access Control). То есть каждому пользователю можно назначить определённую роль для доступа к тому или иному ресурсу.
Ролевая модель
Во вводном курсе про виртуальные машины вы уже познакомились с ролевой моделью Yandex Cloud. Теперь разберем ее подробнее.
Роль — это набор разрешений, которые описывают допустимые операции над ресурсом. После назначения пользователю роли на ресурс он сможет выполнять заданный набор операций над этим ресурсом.
Роли на ресурс назначаются в виде списка связей «роль — субъект». Такие связи называются привязками прав доступа (access bindings), их можно добавлять и удалять, то есть контролировать права доступа к ресурсу.
Одна привязка — это назначение субъекту одной роли. Чтобы назначить пользователю несколько ролей на один ресурс, нужно задать отдельную привязку для каждой из них.
Роли наследуются: все разрешения от родительского ресурса переходят на его дочерние ресурсы. Например, если назначить пользователю роль на каталог, в котором есть виртуальная машина, то все разрешения этой роли будут действовать и для виртуальной машины.
Если у пользователя есть роли и на родительский, и на дочерний ресурс, то для дочернего ресурса будет действовать объединенный список разрешений. Иными словами, ограничить список разрешений, унаследованных от родительского ресурса, на уровне дочернего не получится.
В реализованной в Yandex Cloud ролевой модели имеется два типа ролей: примитивные (общие для всех сервисов) и сервисные (выдаются только на один сервис). Сервисные роли зависят от специфики каждого отдельного сервиса и могут назначаться на объекты, для которых эти роли предназначены. Некоторые сервисные роли назначаются на ресурс (например на ключ шифрования в сервисе KMS), а некоторые — только на контейнер, в котором размещены ресурсы (например роль
compute.admin назначается на каталог или облако).К примитивным ролям относятся:
-
viewer— позволяет просматривать информацию о ресурсе или список ресурсов, если назначена на каталог; -
editor— позволяет управлять ресурсами: создавать, изменять и удалять объекты; -
admin— позволяет управлять ресурсами и правами доступа к ним.
Примитивные роли стоит использовать только для быстрой настройки и тестирования инфраструктуры. Сервисные роли обеспечивают более гранулярный контроль, учитывающий специфику каждого отдельного сервиса.
Для каждого сервиса можно расписать структуру ролей в виде иерархии, где разрешения нижележащих ролей входят в обобщённые вышележащие роли.
Например, в сервисе управления ключами шифрования (KMS) реализована следующая структура ролей.
Примитивные роли
admin, editor, viewer позволяют управлять или просматривать информацию о сервисе в целом. Сервисные роли обеспечивают гранулированное разделение прав.Так, например, роль
kms.admin предоставляет права на администрирование ключей: их просмотр, создание, изменение, удаление, ротацию, шифрование и расшифрование данных. Она также позволяет назначать роль kms.keys.encrypterDecrypter на конкретные ключи. Роль kms.keys.encrypterDecrypter — пользовательская. Она позволяет выполнять операции шифрования и расшифрования для указанных ключей и просматривать информацию о ключе. Но управлять жизненным циклом ключей с ее помощью нельзя.Разрешения роли
kms.keys.encrypterDecrypter входят в разрешения ролей kms.admin и editor. А разрешения kms.admin входят в разрешения примитивной роли admin.Управление ролями
Владелец облака обладает ролью
resource-manager.clouds.owner. Она позволяет выполнять любые операции с облаком и ресурсами в нём.Вторая важная роль — это
resource-manager.clouds.member, участник облака. Она дает возможность пользователю с Яндекс ID пройти аутентификацию в облаке и необходима для выполнения операций с ресурсами. Например, если у пользователя есть роли resource-manager.clouds.member и editor, то он сможет управлять ресурсами облака. Но если роль resource-manager.clouds.member отозвать, то управлять уже не сможет, несмотря на наличие роли editor.Исключение здесь составляют ресурсы с публичным доступом. Для управления ими роль
resource-manager.clouds.member не требуется, доступ к ним можно предоставить иначе.Рассмотрим сценарий использования сервисных ролей на примере сервиса KMS.
-
Владелец (роль
resource-manager.clouds.owner) или администратор (рольadmin) облака назначает рольkms.adminадминистратору KMS. -
Администратор KMS создаёт необходимые ключи шифрования и назначает роли для их использования с помощью интерфейса командной строки (CLI) или API.
-
Пользователи или сервисные аккаунты получают роль
kms.keys.encrypterDecrypterна необходимые им ключи шифрования.
В самом сервисе IAM используется роль
iam.serviceAccounts.user. Эта роль предоставляет пользователю права на использование сервисных аккаунтов. Например, при создании группы виртуальных машин вы хотите использовать ваш сервисный аккаунт, у которого есть права на эту операцию, вместо своего пользовательского аккаунта. Сервис IAM проверяет, есть ли у вас разрешение на использование этого сервисного аккаунта, и разрешает или запрещает данную операцию.В роль
iam.serviceAccounts.user входит следующий набор разрешений:-
получение списка сервисных аккаунтов;
-
получение информации о сервисном аккаунте;
-
использование сервисного аккаунта при выполнении операций от его имени.
Основные теоретические знания о том, как работает сервис IAM, у вас теперь есть. На следующем уроке вы проверите, как это всё работает на практике.