Нет необходимости создавать отдельную роль для каждого клиента (учетной записи), но вы должны убедиться, что вы правильно обрабатываете внешние идентификаторы.
Для каждого из ваших клиентов вы должны создать внешний идентификатор, который будет использоваться только вами и этим конкретным клиентом, чтобы избежать путаницы с депутатами.
После того, как вы настроили внешние идентификаторы для всех своих клиентов, вы можете изменить политику доверия роли, включив в нее отдельный оператор для каждого из ваших клиентов, где вы проверяете, является ли он доверенным участником (идентификатором учетной записи) и соответствующий внешний идентификатор был передан в качестве аргумента sts:assumeRole
call.
Предположим, у вас есть роль, которую могут занять два клиента. Первый идентификатор учетной записи - 1111
, а внешний идентификатор для этого клиента - aaaa
. Идентификатор второй учетной записи - 2222
, а внешний идентификатор для этого клиента - bbbb
. Ваша политика доверия должна выглядеть следующим образом.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::1111:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "aaaa"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::2222:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "bbbb"
}
}
}
]
}
Обратите внимание, что вы, вероятно, хотите использовать GUID для внешних идентификаторов, а не aaaa
или bbbb
.