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?
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.