Amazon web services 在AWS控制台中，除了AssumeRole之外，还需要哪些权限才能将角色切换到另一个帐户？

我有一个：

• AccountB

  myrole

  中的IAM角色与AccountA具有信任关系
• AccountB中的角色具有与关联的策略
• AccountA中的IAM用户，其策略允许帐户B中的角色

  AssumeRole

这适用于我的测试用户，其中仅附加了允许

sts:AssumeRole

的策略

但是我在AccountA中有一个用户，在aws控制台中的开关角色操作会给我一个“一个或多个字段中的无效信息。请检查您的信息或与管理员联系”

但是当我为AccountA中的该用户执行

aws sts承担角色时--角色arn:aws:iam:：xxxxxxxxx:role/myrole--角色会话名称yyyy

，它成功地承担了角色所以我知道sts:AssumeRole没有被拒绝。

我知道这是导致它的

denyalloutsideu

策略，因为如果我将

sts:

添加到帐户中

denyalloutsideu

策略的

NotAction

列表中，it将开始工作

那么，sts:AssumeRole之后到底发生了什么，以及需要哪些其他被拒绝的权限。我知道我可以通过将

sts:

添加到

DenyAllOutsideEU

来修复它，但我想确切地了解发生了什么。我希望在成功的

sts:AssumeRole

之后，AWS控制台不会进一步请求AccountA，因此AccountA中用户的权限都无关紧要，但情况显然并非如此

---

AWS控制台是否正在对AccountA中的其他STS请求用户执行

STS:AssumeRole

之后的另一个区域？

抱歉，跳过它是一个

注释

；删除了我的答案。唯一的另一个想法是该用户正在使用联合登录来访问控制台？没有太多的STS电话值得怀疑。FWIW，我查看了我们的CloudTrail日志，只看到了

AssumeRole

；这可能并不意味着什么，因为CloudTrail并不能捕获所有内容。对不起，跳过它是一个

注释；删除了我的答案。唯一的另一个想法是该用户正在使用联合登录来访问控制台？没有太多的STS电话值得怀疑。FWIW，我查看了我们的CloudTrail日志，只看到了
AssumeRole
；这可能并不意味着什么，因为CloudTrail并不能捕获所有内容。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideEU",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-west-1"
                    ]}}}]}