AWS IAM 角色信任关系是否与基于资源的策略相当？

Question

tl;如果您熟悉 IAM 角色在信任关系方面的行为，请在底部阅读。

我为描述我的问题而创建的设置：

四个角色

arn:aws:iam::<account-id>:role/A
arn:aws:iam::<account-id>:role/B
arn:aws:iam::<account-id>:role/X
arn:aws:iam::<account-id>:role/Y

还有一个用户 arn:aws:iam::<account-id>:user/Test 能够通过信任关系直接担任角色 A 和 B：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account-id>:user/Test"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

用户Test 只是为了让我轻松切换到角色A 和B。在下文中，我使用“担任角色 A 或 B”作为起点，这很容易通过 CLI 上的 aws sts assume-role 完成。

角色A配置

内联政策：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::<account-id>:role/X",
                "arn:aws:iam::<account-id>:role/Y"
            ]
        }
    ]
}

信任关系如上所述，不应该相关。

角色 B 配置

除了上面不相关的信任关系外，没有任何额外的配置。

角色 X 配置

信任关系：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account-id>:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

角色 Y 配置

信任关系：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account-id>:role/B"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

总结差异：A 有权访问 X 和 Y 作为内联策略。 B 没有类似的东西，但B 在Y 的信任关系中被明确授予。 X 只允许帐户访问，不允许特定用户访问。

A 测试

如果您假设 A 调用 aws sts get-caller-identity 应该返回类似

{
    "UserId": "<role-id>:test-session-A",
    "Account": "<account-id>",
    "Arn": "arn:aws:sts::<account-id>:assumed-role/A/test-session-A"
}

如果您现在执行aws sts assume-role --role-arn arn:aws:iam::<account-id>:role/X --role-session-name a-assume-x，您确实会收到带有凭据的有效响应。如果您对Y 执行相同操作，则会得到AccessDenied [...] User [...] is not authorized to perform: sts:AssumeRole [...]。

这是有道理的，因为Y 与A 没有信任关系。

与 B 的测试

如果您假设 B 调用 aws sts get-caller-identity 应该返回类似

{
    "UserId": "<role-id>:test-session-B",
    "Account": "<account-id>",
    "Arn": "arn:aws:sts::<account-id>:assumed-role/B/test-session-B"
}

现在情况正好相反。如果您尝试假设X，您会得到Access Denied 并假设Y 有效。

假设Y 工作是因为明确授予角色B。当我们首先假设 A 或 B 与用户 Test 时，我们也会使用它。令我困惑的是，假设 X 不起作用。行为本身是有道理的。您允许帐户中的任何内容假定为 X，但您需要一个策略来授予特定用户访问权限。

tl;dr - 我的问题

如果您明确授予某个特定委托人对某个角色的访问权限，则该委托人将获得直接访问权限 - 无需额外的策略。这类似于基于资源的策略。

但是，如果您将整个帐户添加为信任关系，则其行为类似于权限边界。您可以获得访问权限，但您必须为边界内的主体创建一个策略才能实际承担。

这让我很困惑。什么是信任关系？这种行为背后的规则是什么？

额外问题：这是否也适用于其他可以建立信任关系的服务，如 Lambda 或 RDS？

Answer 1

不确定如何回答这个问题，因为您基本上已经知道什么是信任关系。
他们指定了如何承担一个角色，特别是他们可以

• 授予对特定实体的访问权限：角色、用户、idp、...和/或
• 授予对特定帐户的访问权限以委派访问权限

在第一种情况下，这就是你所需要的。

在第二种情况下，您还需要一个附加策略，允许您进行assumeRole 操作。该帐户授予包括您自己的帐户。没有信任关系的角色不能由任何人担任，不在同一个帐户中，也不是跨帐户。不知道为什么会这样决定，我可以想象原因基本上是“只是因为角色在您的帐户中，并不是该帐户中的每个人都应该能够承担它”。

这与例如KMS 密钥策略有效。

---

它们不完全符合the policy evaluation docs 中基于资源的策略的工作方式，但如果您将它们视为cross-account resource-based policies，则它们最适合，此时双方都需要授予操作权限才能真正被允许。