Are AWS service principals implicitly account scoped in policy documents?

Question

Consider the following trust relationship configured for an IAM role in accountA:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudformation.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Does this implicitly scope the access down to cloudformation running in accountA, or can cloudformation stack in any other account (B,C,D,etc) assume this role?

I've used sourceArn conditions previously to avoid deputy attacks, like this:

"Condition": {
        "ArnLike": {
          "aws:SourceArn": [
            "xxxx"
           ]
        }
 }

Is this necessary, or is the initial policy sufficient to scope the trust relationship down to accountA?

Answer 1

This policy is allowing the CloudFormation service to assume a role that is in your account.

By default this is also scoped to your account, i.e. only CloudFormation in your account can assume the role and not CloudFormation from another account. You would have to explicitly add a Principal with another account ID to allow cross account access from CloudFormation in another account - that would look like this:

"Principal": {
    "AWS": "123456789012"
    "Service": "cloudformation.amazonaws.com"
},

To be clear the user would need to have the following permissions to allow them to pass the role to the service.

• "iam:GetRole"
• "iam:PassRole"

Without these permissions for your IAM role Arn they cannot pass it to the CloudFormation service to allow it to be assumed.

So in short the permissions to pass the IAM role arn are needed on a user/role in addition to the service being able to assume a role.

More information is available in the Granting a user permissions to pass a role to an AWS service documentation.