Как устроено управление доступом в Yandex Cloud
На этой странице можно узнать, как управлять доступом к ресурсам, и как IAM проверяет права доступа к ним.
Как проверяются права доступа?
Все операции в Yandex Cloud предварительно отправляются на проверку в IAM, например:
- Пользователь просит сервис Compute Cloud создать новый диск в каталоге
default
. - Сервис спрашивает IAM, можно ли этому пользователю создать диск в этом каталоге.
- IAM проверяет, что пользователь — участник облака с каталогом
default
и имеет необходимые разрешения для создания диска в этом каталоге. - Если какого-то из разрешений у пользователя нет, операция не будет выполнена, и Yandex Cloud сообщит об ошибке.
Если все разрешения имеются, то IAM сообщает об этом сервису. - Сервис создает новый диск.
Как вы управляете доступом?
Управление доступом в Yandex Cloud построено на политике Role Based Access Control
Чтобы назначить роль, вы выбираете ресурс, выбираете роль и описываете субъект, которому назначается роль. Таким образом вы назначаете права доступа к ресурсу.
Вы также можете назначить роль на родительский ресурс, от которого наследуются права доступа, например назначить роль на каталог или облако.
Важно
Изменение прав доступа обычно занимает до 5 секунд. Если после назначения роли все еще нет доступа, попробуйте выполнить операцию еще раз.
Например, вам разрешили создавать каталоги в облаке и вы уже создали один каталог, но не смогли создать второй. Это произошло потому, что еще не обновились права доступа на том сервере, где выполнялась вторая операция по созданию каталога. Попробуйте создать каталог еще раз.
Ресурсы, на которые можно назначать роли
Назначать роли можно на облако, каталог и другие ресурсы из списка. Если нужно предоставить доступ к ресурсу, которого нет в списке, назначьте роль на родительский ресурс, от которого наследуются права доступа. Например, у кластеров Yandex Managed Service for PostgreSQL права доступа наследуются от каталога.
Роль
Назначать роли на ресурс могут пользователи, у которых на этот ресурс есть хотя бы одна из ролей:
admin
;resource-manager.admin
;organization-manager.admin
;resource-manager.clouds.owner
;organization-manager.organizations.owner
.
Таким образом, назначать роли на ресурс могут пользователи с ролью администратора на облако или организацию, а также владельцы облака или организации, к которым относится ресурс.
Каждая роль состоит из набора разрешений, описывающих допустимые операции с ресурсом. Пользователь может назначить роли только с теми разрешениями, которые имеются у него самого. Например, чтобы назначить роль владельца облака, пользователь должен сам обладать этой ролью, а роли администратора для этого недостаточно.
О том, какие есть роли и какие разрешения в них входят, читайте в разделе Роли.
Субъект, которому назначается роль
Роли назначаются субъектам. Существуют следующие типы субъектов:
-
userAccount
— аккаунт на Яндексе, добавленный в Yandex Cloud:Идентификатор субъекта:
userAccount:<идентификатор_пользователя>
.Где
<идентификатор_пользователя>
— уникальный идентификатор, присвоенный пользователю. Например:userAccount:ajecpdmpr4pr********
. -
serviceAccount
— сервисный аккаунт, созданный в Yandex Cloud:Идентификатор субъекта:
serviceAccount:<идентификатор_сервисного_аккаунта>
.Где
<идентификатор_сервисного_аккаунта>
— уникальный идентификатор, присвоенный сервисному аккаунту. Например:serviceAccount:ajevnu4u2q3m********
.Сервисному аккаунту можно назначать роли на любые ресурсы в любом облаке, если эти ресурсы относятся к той же организации, что и сервисный аккаунт. Также сервисному аккаунту можно назначать роли на саму организацию.
-
federatedUser
— аккаунт пользователя федерации удостоверений, например из Active Directory:Идентификатор субъекта:
federatedUser:<идентификатор_пользователя>
.Где
<идентификатор_пользователя>
— уникальный идентификатор, присвоенный федеративному пользователю. Например:federatedUser:aje7b4u65nb6********
. -
group
— группа пользователей Yandex Cloud Organization:-
Группа пользователей, созданная администратором организации:
Идентификатор субъекта:
group:<идентификатор_пользовательской_группы>
.Где
<идентификатор_пользовательской_группы>
— уникальный идентификатор, присвоенный группе пользователей, созданной администратором организации. Например:group:ajeser8mnc4c********
. -
Системная группа
All users in organization X
:Идентификатор субъекта:
group:organization:<идентификатор_организации>:users
.Где
<идентификатор_организации>
— уникальный идентификатор, присвоенный организацииX
. Например:group:organization:bpfaidqca8vd********:users
. -
Системная группа
All users in federation N
:Идентификатор субъекта:
group:federation:<идентификатор_федерации>:users
.Где
<идентификатор_федерации>
— уникальный идентификатор, присвоенный федерации удостоверенийN
. Например:group:federation:bpf8tpgggfoi********:users
.
-
-
system
— публичная группа пользователей:-
Публичная группа пользователей
All authenticated users
:Идентификатор субъекта:
system:allAuthenticatedUsers
. -
Публичная группа
All users
:Идентификатор субъекта:
system:allUsers
.
-
Назначение прав доступа
Роли на ресурс назначаются в виде списка связей роль-субъект. Такие связи называются — назначенные права доступа (access bindings). Вы можете добавлять и удалять эти связи, таким образом контролируя права доступа к ресурсу.
Одна привязка — одно назначение роли субъекту. Чтобы назначить пользователю несколько ролей на ресурс, задайте отдельную привязку для каждой из ролей.
Наследование прав доступа
Если у ресурса есть дочерние ресурсы, то все разрешения от родительского ресурса будут унаследованы дочерними ресурсами. Например, если вы назначите пользователю роль на каталог, в котором лежит виртуальная машина, то все разрешения этой роли будут действовать и для виртуальной машины.
Если на дочерний ресурс тоже назначены роли, то список разрешений на этот ресурс будет объединен со списком разрешений на родительский ресурс. Нельзя ограничить список разрешений, унаследованных от родительского ресурса.
Имперсонация
Имперсонацией называется выполнение пользователем действий с ресурсами облака от имени сервисного аккаунта, которому назначены необходимые права. Имперсонация чаще всего применяется, чтобы временно расширить права пользователя, не прибегая к генерации статических учетных данных.
Например, когда у пользователя нет прав на просмотр каталога, но на какое-то время они ему оказались нужны. Для этого администратор может назначить сервисному аккаунту роль на просмотр каталога, а пользователю назначить специальную роль iam.serviceAccounts.tokenCreator
. В результате пользователь сможет от имени сервисного аккаунта просматривать ресурсы в каталоге или получить IAM-токен сервисного аккаунта. Пользователь не сможет изменить права доступа или удалить сервисный аккаунт.
В нужный момент администратор может отозвать роль.
Ограничения управления доступом в консоли управления
В консоли управления назначение ролей работает с ограничениями:
- Вы не можете назначить роли сразу нескольким субъектам, как в API или CLI. В консоли управления вы сначала выбираете субъект (пользователя или сервисный аккаунт), а затем назначаете ему роли.
Управление доступом сервисов к ресурсам в облаке пользователя
Yandex Identity and Access Management позволяет управлять доступом сервисов к ресурсам в облаке пользователя, при необходимости включая или выключая нужные сервисы.
Доступ сервиса — это совокупность прав доступа, необходимых для создания и функционирования ресурсов этого сервиса в облаке пользователя. Такие права доступа назначаются специальным сервисным аккаунтам — сервисным агентам, от имени которых сервис осуществляет доступ к ресурсам пользователя в облаке.
Пользователь не может напрямую создавать или удалять сервисных агентов. Сервисные агенты в необходимом количестве и с нужными правами доступа автоматически создаются при включении сервисов и автоматически удаляются при их выключении.
См. также
Вы можете найти подробную информацию об управлении доступом для конкретного сервиса Yandex Cloud в разделе Управление доступом
в документации соответствующего сервиса.
Пошаговые инструкции и примеры: