10

I am new to AWS, but from my understanding a role contains both a permissions policy and a trust policy. The permissions policy seems pretty straight forward - What you can do. IE:

                "iam:CreatePolicy",
                "iam:GetRole",
                "iam:GetPolicy",
                "iam:DeletePolicy",
                "iam:CreateRole",
                "iam:DeleteRole",
                 ...

The trust policy on the other hand is the "who is allowed to do it" IE:

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

AssumeRole sounds like a "What you can do", so why does it always belong in the trust policy and not the permissions policy. Going off that, I've learned that sts:TagSession also belongs in the Trust policy and not the permissions policy. Am I missing something or is it simply sts type actions belong in the trust policy?

SteelerKid
  • 304
  • 1
  • 4
  • 15

1 Answers1

14

A role’s trust policy describes who or which service is allowed to assume that role. A role is being assumed by calling sts:AssumeRole.

The reason why the action is explicitly stated is the way AWS IAM policies work. A trust policy is a resource policy, i.e. attached to a resource (in this case an IAM Role), that defines who can do what with that resource.

Assuming a role always needs two policies playing together:

The Principal (e.g. an IAM User) needs the permission to call sts:AssumeRole for that role AND the role must have a trust policy, allowing sts:AssumeRole from the Principal. Only if both conditions are in place, the Principal can assume the role. The Principal must explicitly be allowed AND the Role musst explicitly trust the Principal.

Dennis Traub
  • 50,557
  • 7
  • 93
  • 108
  • I think I get it.. It's a two-way street and the trust has to explicitly be defined both ways. But still, why is sts:AssumeRole not in the Permissions? – SteelerKid May 15 '20 at 16:55
  • 4
    If `sts:AssumeRole` was defined in this role's permissions it would be allowed to assume itself. Which doesn't make any sense. However, a role (let's say role A) could allow the assumption of another role (role B). In this case it would make sense to add a permission to role A, allowing it to `sts:AssumeRole` role B, which in turn would require a trust policy pointing to back to role A. Does that make sense? – Dennis Traub May 15 '20 at 17:28
  • 3
    Yep thanks I finally understand.. I guess I was overlooking the fact that the trust policy is literally there to give permissions as to who can *assume* it(and how - which api call) To reiterate, to assume a role I would have to already have a prexisting permission to call the assumerole api, and the trust policy on the role I'm trying to assume must list my me and the action I can use to assume it(sts:AssumeRole).. Once I've assumed the role, then the permissions policy comes into play. Thanks for the follow up response – SteelerKid May 18 '20 at 00:42
  • @DennisTraub, to clarify please: does this answer apply to a Principal and a Role in two different accounts? I ask because of this statement in the docs: [S1] "When the principal and the resource are in separate AWS accounts, you must also use an identity-based policy to grant the principal access to the resource." [S2] "However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required." Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html – profnotime Jun 19 '22 at 15:13