Can IAM user assume a role, if the user is not described in the Trust policy of the role?

Question

Can a role be assumed if it does not have a Trust policy? If a given IAM user has an attached identity based policy saying that he/she can call sts:AssumeRole for a given role (inside the same account), but the user is not described in the Trust policy of this role, will he/she be able to assume the role?

Usually only the resource based policy or the identity based policy should be enough to give rights for the user, but is it different for the roles?

Thanks

Answer 1

will he/she be able to assume the role?

Yes, of course she/he will be able to do it, as long the trust policy allows the account to assume the role. For example, a role has to have the trust policy of:

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

This way, your IAM user does not need to be explicitly listed in the trust policy, but trust policy is required and at least you should specify the account which can assume it. But the drawback is that any IAM user or role from the <account-number> account that has sts:AssumeRole permissions can assume the role.

it does not have a Trust policy?

Trust policy is required, so you can't have a role without such such a policy.

Update

Lets assume you have a role with a trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxx:user/UserA"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

The role can be assumed only by userA. UserB will not be able to assume this policy, regardless of his permissions.

Answer 2

A Trust Policy specifies the "Principal" which can assume the role it is attached to. That principal can be various different types of entity, such as an AWS service (e.g. to create a role applied to EC2 instances), or the identifier of another AWS account (to grant cross-account access). It cannot be omitted or be a wildcard.

If the principal identifies an AWS account, then it is trusting the AWS account as a whole. In a sense, all users in that account have been included in the trust policy, but to assume the role they also need permission to make the appropriate AssumeRole API call. This delegates responsibility to the administrator of the other AWS account to decide which users should be able to assume the role.

This can be used to create a hierarchical arrangement of accounts:

• All users are created in a single AWS account, which has no other resources.
• The actual resources - EC2 instances, S3 buckets, etc - are in separate AWS accounts.
• Each account defines roles granting access to some of these services, with a trust policy listing the central account as the Principal. These roles do not list individual users or groups as trusted, they just define sets of permissions.
• The users in the central account are each granted AssumeRole access to an appropriate subset of the roles in the different accounts. The effect is similar to using Groups or Managed Policies to grant multiple users the same access.