Reputation: 3054
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?
Upvotes: 10
Views: 3322
Reputation: 21194
DynamoDB does not support authorization based on tags so what you are trying to do won't work. see here for a list of services that do.
Upvotes: 1
Reputation: 5665
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-tag
for 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_.
Upvotes: 12