为什么角色的信任策略中包含 sts:AssumeRole 而不是权限策略中?

Ste*_*Kid 10 roles amazon-web-services amazon-iam aws-policies

我是 AWS 新手,但根据我的理解,角色既包含权限策略又包含信任策略。权限策略看起来非常简单——你可以做什么。IE:

                "iam:CreatePolicy",
                "iam:GetRole",
                "iam:GetPolicy",
                "iam:DeletePolicy",
                "iam:CreateRole",
                "iam:DeleteRole",
                 ...
Run Code Online (Sandbox Code Playgroud)

另一方面,信任策略是“谁被允许这样做”IE:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::000000000000:role/My-Role"
      },
      **"Action": "sts:AssumeRole"**
    }
  ]
}
Run Code Online (Sandbox Code Playgroud)

AssumeRole 听起来像是“你可以做什么”,那么为什么它总是属于信任策略而不是权限策略。继续下去,我了解到 sts:TagSession 也属于信任策略而不是权限策略。我是否遗漏了某些内容,或者它只是属于信任策略中的 sts 类型操作?

Den*_*aub 15

角色\xe2\x80\x99s 信任策略描述了允许谁或哪个服务承担该角色。通过调用 sts:AssumeRole 来承担角色。

\n\n

明确说明该操作的原因是 AWS IAM 策略的工作方式。信任策略是一种资源策略,即附加到资源(在本例中为 IAM 角色),它定义可以对该资源执行什么操作。

\n\n

扮演一个角色总是需要两个策略一起发挥作用:

\n\n

委托人(例如 IAM 用户)需要为该角色调用 sts:AssumeRole 的权限,并且该角色必须具有信任策略,允许来自委托人的 sts:AssumeRole。只有当这两个条件都具备时,校长才能担任这一角色。必须明确允许委托人,并且角色必须明确信任委托人。

\n

  • 如果在此角色的权限中定义了“sts:AssumeRole”,则将允许其自行承担。这没有任何意义。然而,一个角色(假设角色 A)可以允许承担另一个角色(角色 B)。在这种情况下,向角色 A 添加权限是有意义的,允许其“sts:AssumeRole”角色 B,而这又需要一个指向角色 A 的信任策略。这有意义吗? (4认同)
  • 是的,谢谢,我终于明白了..我想我忽略了这样一个事实,即信任策略实际上是为了授予谁可以“承担”它的权限(以及如何 - 哪个 api 调用)重申一下,承担我将拥有的角色已经拥有调用假设角色 api 的预先存在的权限,并且我尝试承担的角色的信任策略必须列出我自己以及我可以用来承担它的操作(sts:AssumeRole)..一旦我承担了角色,然后权限策略就发挥作用。感谢您的后续回复 (3认同)