У меня есть:
- роль IAM в AccountB
myrole
с доверительными отношениями к AccountA - роль в AccountB имеет политику, связанную с , разрешающей только
eu-north-1
. - пользователь IAM в AccountA с политикой, разрешающей
AssumeRole
выполнять роль myrole
в учетной записи B
Этот работает для моего тестовый пользователь , к которому присоединена только эта политика, разрешающая sts:AssumeRole
.
Но у меня есть пользователь в AccountA с DenyAllOutsideEU
политикой , где операция переключения роли в * Консоль 1054 * выдает мне « Неверная информация в одном или нескольких полях. Проверьте информацию или обратитесь к администратору ».
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideEU",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-west-1"
]}}}]}
Но когда я делаю aws sts assume-role --role-arn arn:aws:iam::xxxxxxxxx:role/myrole --role-session-name yyyy
для этого пользователя в AccountA, он успешно принимает роль. Итак, я знаю, что sts:AssumeRole
не запрещается.
Я знаю, что это политика DenyAllOutsideEU
, которая вызывает его, потому что, если я добавлю sts:*
в список NotAction
в политике DenyAllOutsideEu
в учетной записи A начнет работать .
Итак, что именно происходит после sts:AssumeRole
, и какое еще разрешение требуется, но в нем отказано. Я знаю, что могу просто исправить, добавив sts:*
к DenyAllOutsideEU
, но я хочу точно понять, что происходит. Я ожидал, что после успешного выполнения sts:AssumeRole
консоль AWS не будет выполнять дальнейший запрос к AccountA, поэтому ни одно из разрешений пользователя в AccountA не будет иметь значения, но это, очевидно, не так.
Является ли AWS Консоль, выполняющая какой-либо другой запрос STS пользователя в AccountA в направлении другого региона после sts:AssumeRole
?