7

我正在尝试创建一个 IAM 策略，让用户可以完全访问 dynamodb，但需要注意的是表必须具有Stage带有值的标签Dev。基本上您可以创建一个表，但您应该在其上添加Stage带有值Dev的标签。您只能查看/更新等标签为Stage=Dev.

AWS 文档提到了一种使用Global Context Keys轻松做到这一点的方法：aws:ResourceTag

但是当我使用可视化编辑器时，我在上下文键列表中找不到键。如果我手动编辑 JSON 并添加它，我会收到警告condition key is not supported

这是我的政策：

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

我在这里可能做错了什么？

4

2 回答 2

9

我认为你没有做错任何事。AWS 文档不正确且具有误导性。aws:ResourceTag不是此处所述的全局条件键。

全局条件键是带有 aws: 前缀的条件键。AWS 服务可以提供包含服务前缀的服务特定密钥。例如，IAM 条件键包括 iam: 前缀。

根据文档，任何带有 aws: 前缀的条件都是全局条件。但是，如果您查看其他服务的条件，例如 IOT，您将看到带有aws:前缀的服务特定条件，这与文档冲突。

物联网服务水平条件

然而，ECR 将ecr:ResourceTag和都aws:ResourceTag列为服务特定条件。

ECR 服务级别条件

另一方面，EC2 只有ec2:ResourceTag. RDS 也有rds:db-tag同样的目的。但是，DynamoDb 没有用于此目的的服务特定标签。

简而言之，aws:ResourceTag 不是全局条件键。一些服务使用 aws: 前缀创建特定于服务的标签，即使它们不应该这样做以符合 AWS 命名约定。

我建议您为开发资源创建一个单独的帐户。如果您不能这样做，您可以尝试更改策略中的逻辑作为一种解决方法，例如，代替标记条件，在您的策略中应用命名约定，例如以 dev_ 开头的任何表。

于 2019-11-22T13:17:20.160 回答
1

DynamoDB 不支持基于标签的授权，因此您尝试执行的操作将不起作用。请参阅此处以获取执行此操作的服务列表。

于 2020-02-12T10:25:28.350 回答