Resource-based policies and implicit denies in other policy types (same account)

[zackriso]

In the table provided here (under the section resource-based policies): https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

The "IAM Role Session" is listed twice as the principal making the request in that table. In the first instance, it mentions "Allows Role ARN" and in the second, it mentions "Allows Role session ARN".

What is not clear to me is: How can we allow a Role ARN for a Role Session ARN? Is not the fact that it is a Role Session, it would always be equal to the following format: arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

In other words, in which scenario (or example) would the "Allows Role ARN" work with a "IAM role session"? Could you please provide an example or clarify this point please?

[bonniekeller]

It's meant to help you understand the impact of policy evaluation specific to resource-based policies, depending on which ARN you specified in the resource-based policy. If the role session ARN is what's specified in the resource-based policy, then other policy types are not evaluated.

[zackriso]

Yes, I understood the logic behind it.

In the example of "IAM Role session" just below the table, the following format is explicitly given: arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

However, there are 2 entries of "IAM Role Session" in that table, so I would like to know how can a "IAM role session" accept a traditional "Role ARN" as a value, as mentioned in that table? Can we inject an regular role ARN under a "Role Session ARN"? If not, then the table should be updated

[bonniekeller]

The table is about who is trying to take the action. When you assume a role and then attempt to take an action, the principal trying to take the action is the ARN of the role session, not the ARN of the role itself. It's not about an IAM role session accepting a role ARN as a value.

[zackriso]

Yes, this is more clear, however:

I did a test with an IAM user, where I put a deny S3 on all actions in his identity policy as below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "*"
        }
    ]
}

and under the S3 bucket resource policy itself, I allowed that user all actions on S3 as below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123123123123:user/MyUser123"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::mybucket/*",
                "arn:aws:s3:::mybucket"
            ]
        }
    ]
}

according to the table, the request should be Allowed, if the request is coming from the IAM user itself (which is the case), and the resource-based policy allows it (which is also the case), even if the identity policy denies access (also the case). However, the request is actually denied. Am I misunderstanding something?

[bonniekeller]

The table covers the impacts of implicit denies. An explicit deny (your first policy) trumps all.

[zackriso]

Indeed, I missed that part.

One last thing. Under the IAM Role row, it says "A role itself cannot make a request. Requests are made with the role session after a role is assumed."

However, under "IAM role session", the Resource-based policy says "Allows Role Arn", would not that not apply since the IAM Role itself cannot make requests as mentioned in the row before it?

Thanks for your help and answers.

[bonniekeller]

Keep in mind this is about the impact of resource-based policies on policy evaluation. The principal making the request is still the role session. The table illustrates what the combination of policies will result in.

[zackriso]

I understand, I just feel there are contradictions with the way the table is presented, in some cases we mention it is "N/A", and in others we treat it as a potentially valid entry in the resource policy.

Anyhow, I also consider an allow in a resource policy as an "explicit allow" in the evaluation logic, so in my opinion, it would be "normal" that the final result is allowed, even with the implicit denies.