Что такое «Предполагать» роль в AWS?
Вопрос
Что именно означает «Предполагать роль» в AWS и где дается окончательное определение?
Задний план
Принимая на себя роль часто используется и пытается понять определение и то, что оно на самом деле означает.
Я предполагаю, что принципал (пользователь IAM, приложение, работающее в экземпляре EC2 и т. д., Которое вызывает действие для доступа к ресурсу (ам) AWS) должен вызвать действие для доступа к ресурсу AWS:
AWS (API? Или некоторая среда выполнения авторизации в AWS?) Определяет роли, которые может быть предоставлен участнику.
например. если пользователь EC2 указан для выполнения вызова API с предполагаемой ролью и запуска приложения, которое обращается к ресурсам AWS в экземпляре EC2, к которому прикреплен профиль IAM, тогда:- Все роли IAM из профиля IAM EC2
- Роли и политики IAM, запрошенные в вызове accept-role
- Роли IAM, предоставляемые пользователю EC2
AWS находит роль из ролей, у которых есть политика (действие, ресурс), которая позволяет принципу выполнять действие с ресурсом.
- AWS переключает роль принципа на определенную роль.
Когда происходит шаг 3, говорят, что «принципал взял на себя роль». Это правильно?
Исследовать
Before an IAM user, application, or service can use a role that you created, you must grant permissions to switch to the role. You can use any policy attached to one of an IAM user's groups or to the user itself to grant the necessary permissions.
Ответы 3
When step 3 has happened, it is said: "the principal has assumed the role". Is this correct?
Шаги, которые вы упомянули при принятии роли, - верный.
Здесь важным моментом является конфигурация доверительных отношений роли IAM, в которой вы предоставляете каждому пользователю, приложению или службе IAM возможность взять на себя эту роль. Именно здесь вы даете разрешение на выполнение определенной роли.
Это важно во многих аспектах, где контролируется, кто может взять на себя роль, и важно не только предоставить наименьший доступ к роли, но также предоставить наименьшее количество сущностей, которые могут взять на себя эту роль.
Предположение о роли означает запрос у службы маркеров безопасности (STS) с просьбой предоставить вам набор временных учетных данных - учетных данных роли - которые относятся к той роли, которую вы хотите принять. (В частности, новый «сеанс» с этой ролью.)
При желании вы можете включить в этот запрос политику, которая будет служить для ограничения разрешений временных учетных данных только подмножеством того, что было разрешено политиками роли.
Затем вы используете эти учетные данные для дальнейших запросов. Эти учетные данные похожи на учетные данные пользователя IAM с идентификатором ключа доступа и секретом, но ключ доступа начинается с ASIA вместо AKIA, и есть третий элемент, называемый токеном безопасности, который должен быть включен в запросы, подписанные с временными учетными данными. .
Когда вы делаете запросы с этими временными учетными данными, у вас есть разрешения, связанные с ролью, а не ваши собственные (если она у вас есть), потому что вы приняли новое удостоверение. CloudTrail можно использовать для отслеживания учетных данных роли до пользователя, взявшего на себя роль, но в противном случае служба не знает, кто использует учетные данные.
tl; dr: принятие роли означает получение набора временных учетных данных, которые связаны с ролью, а не с сущностью, которая взяла на себя роль.
AWS (API? or some Authorisation runtime in AWS?) identifies the roles which the principal can be granted.
Нет. Вы указываете роль, которую хотите принять.
Когда «вы» - это код, работающий в экземпляре EC2, и у этого экземпляра есть роль экземпляра, инфраструктура EC2 фактически вызывает accept-role от имени экземпляра, и вы можете получить временные учетные данные из служба метаданных экземпляра. Эти учетные данные доступны только из экземпляра, но не хранятся в экземпляре.
При запуске функции Lambda инфраструктура Lambda связывается с STS и помещает ваши временные учетные данные в переменные среды. Опять же, эти учетные данные доступны для функции, но не хранятся внутри функции.
В любом случае вы можете вызвать accept role с этими учетными данными и взять на себя другую роль, но в большинстве сред это не обязательно.
e.g. if an EC2 user is specified to execute the assume-role API call and run an application which accesses an AWS resources in an EC2 instance to which IAM profile is attached, then:
AWS ничего не знает о EC2 пользователи. Роли экземпляра доступны для всего, что запущено на экземпляре.
All the IAM roles from the EC2 IAM profile
Профиль экземпляра может включать только одну роль.
IAM roles and policies requested in the assume-role call
Вы просите взять на себя ровно одну роль. Вам не нужно запрашивать политику - вы указываете политику только в том случае, если хотите, чтобы временные учетные данные имели привилегии меньше, чем позволяли учетные данные роли. Это может быть то, что вы сделали бы, если вам нужен код, работающий в ненадежном месте, например код в браузере или приложении, чтобы иметь возможность подписывать запросы с помощью учетных данных.
AWS finds a role from the roles which has the policy (action, resource) that allows the principle to do the action on the resource.
Нет. Как отмечалось выше, вы запрашиваете конкретную роль, когда вызываете accept-role.
AWS switches the role of the principle to the role identified.
Нет. Ты выполняет переключение, используя предоставленные временные учетные данные.
@SheelPancholi EC2 услуга принимает на себя роль и делает учетные данные доступными для пример - любой и все пользователи ОС на экземпляре могут получить доступ к учетным данным роли через службу метаданных экземпляра, как упоминалось выше.
Скажем, у меня есть роли A и B. Не могли бы вы сказать мне, каковы «преимущества» принятия роли B пользователем A вместо того, чтобы просто устанавливать необходимые разрешения для A (предоставленные B) самостоятельно?
@Tomasz, если обе роли являются ролями в вашей учетной записи, не так много очевидных причин, по которым это было бы полезно.
@programming_and_math Вместо роли IAM A и роли IAM B чаще можно увидеть IAM Пользователь A и роль B IAM, где роль B IAM предоставляет некоторые более высокие разрешения, например возможность читать конфиденциальные журналы в корзине S3. Значение роли B по сравнению с простым предоставлением пользователю A доступа к корзине заключается в том, что учетные данные пользователя IAM являются долгосрочными, а учетные данные роли IAM / STS - краткосрочными. Раскрытие учетных данных STS снижает риск. Вы также можете потребовать MFA при принятии роли B, хотя обычно для пользователя IAM может быть обременительным предоставление MFA для повседневного использования.
Я создал для себя следующую диаграмму, чтобы понять, что именно подразумевает роль в AWS. Надеюсь, вы тоже найдете это полезным.
На схеме я поместил это в 3 шага:
- Подготовьте роли (ExecutionRole и AssumedRole)
- Создайте лямбда-функцию в учетной записи A (в вашем случае это EC2)
- Выполните LambdaFunction.
На диаграмме в качестве примера используется перекрестный счет, если он находится в одной учетной записи, шаг 1.3 не требуется.
Typically, you use AssumeRole within your account or for cross-account access. ... Users in the same account as the role do not need explicit permission to assume the role.
Source: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
Итак, когда я прикрепляю роль «X» к экземпляру EC2, экземпляр EC2 «принимает» эту роль? И когда я затем использую «ec2-user» для выполнения запроса «aws s3 cp ...», «ec2-user» использует учетные данные, доступные экземпляру EC2 в результате принятия на себя роли X?