AWS IAM: How does the condition context key "aws:RequestTag" work?

Question

I have an EC2 instance with a role attached to it. My goal is to provide full access to AWS service (Lambda for example) but only on certain resources (Tag based). I found that aws:RequestTag was the way to do it.

Below is the IAM policy attached to the role.

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1614664562621",
            "Action": "lambda:*",
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "aws:ResourceTag/app": "prod"
                }
            }
        }
    ]
}

I added the tags app:prod on the required lambda functions but however when I try to list the lambda I get an AccessDeniedException error. Below is the error message

An error occurred (AccessDeniedException) when calling the ListFunctions operation: User: arn:aws:sts::123456789:assumed-role/iam-role-name/i-01abcd456abcd is not authorized to perform: lambda:ListFunctions on resource: *

How to make the aws:RequestTag work? Where am I going wrong?

Similar question below: (That solution didn't work for me) aws:RequestTag on s3 bucket is not working (while assuming a role)

Answer 1

You probably want to use aws:ResourceTag instead in your condition and tag the resources (i.e. Lambda functions) that this policy should permit access to.

aws:RequestTag is used to control which tags can be carried in an AWS API call such as for adding/editing/removing a resource tag on a resource or adding session tags on a session (via an sts:TagSession call). They are not meant to protect access to resources having a specific tag.

Also, adding the tag on your role does not mean that any caller identity (i.e. assumed session role) will then have this tag as a request/session tag. And consequently, it will not control any authorization/access to resources with that tag. The IAM role that you tagged simply is another AWS resource with a resource tag applied to it now.

Additionally, you couldn't even control session tags when EC2 assumes your role in the EC2 instance, so you cannot control session/request tags for your EC2 instance.

EDIT: In your particular example with lambda:ListFunctions, though, which is not a resource-specific action, you cannot control/filter the list by Lambda functions having a specific resource tag allowed by the policy of the API caller.

When working with multiple environments/stages, having multiple AWS accounts (one per environment/stage) is actually best practice. You can then even use AWS Organizations for consolidated billing, etc. if you don't already use multiple AWS accounts.