IAM Policy with `aws:ResourceTag` not supported

Question

I am trying to create an IAM policy that gives users complete access to dynamodb with the caveat that the tables must have the tag Stage with value Dev on it. Basically you can create a table but you should add tag Stage with value Dev on it. You can view/update etc only those tables that have tag as Stage=Dev.

AWS documentation mentions a way to do that easily using Global Context Keys: aws:ResourceTag

But when I use the visual editor I can't find the key in the list of context keys. If I manually edit the JSON and add the same, I am getting the warning condition key is not supported

Here is my policy:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "OnlyDynamoDBWithTagValueDev",
        "Effect": "Allow",
        "Action": "dynamodb:*",
        "Resource": "arn:aws:dynamodb:*:accountnumber:table/*",
        "Condition": {
            "StringEquals": {
                "aws:ResourceTag/Stage": "Dev"
            }
        }
    }
]}

What I might be doing wrong here?

Answer 1

I think you are not doing anything wrong. AWS documentation is just incorrect and misleading. aws:ResourceTag is not a global condition key as stated here.

Global condition keys are condition keys with an aws: prefix. AWS services can provide service-specific keys that include the service prefix. For example, IAM condition keys include the iam: prefix.

According to the documentation, any condition with aws: prefix is a global one. However, if you view conditions for other services, e.g IOT, you will see a service-specific condition with aws: prefix, which conflicts with the documentation.

Whereas, ECR lists both ecr:ResourceTag and aws:ResourceTag conditions as service-specific conditions.

EC2, on the other hand, only has ec2:ResourceTag. RDS has rds:db-tagfor the same purpose. However, DynamoDb has no service-specific tags for this purpose.

In short, aws:ResourceTag is not a global condition key. Some services create service-specific tags with aws: prefix, even though they are not supposed to do so to align with AWS naming conventions.

I recommend that you create a separate account for development resources. If you can't do that, you can try changing the logic in your policy as a workaround, e.g. instead of tag conditions, apply naming conventions in your policies, e.g. any table that starts with dev_.