How can I control user access to Amazon DynamoDB data via IAM?

Question

Does AWS Identity and Access Management (IAM) provide a way so that a user can only edit or delete the items in an Amazon DynamoDB table he added before?

Answer 1

You can add an IAM user that is restricted to the PutItem/UpdateItem/DeleteItem DynamoDB actions and that is restricted to a specific table by ARN. See Using IAM to Control Access to Amazon DynamoDB Resources.

You can use resource-level ARNs in IAM policies for all Amazon DynamoDB actions, except ListTables.

There's no inbuilt way to restrict table updates to 'the user who created the table', however, but you could script that at table creation time, I guess.

Answer 2

This became possible after AWS added Fine-Grained Access Control for Amazon DynamoDB, which facilitates AWS Identity and Access Management (IAM) policies to regulate access to items and attributes stored in DynamoDB tables.

The introductory blog post illustrates the outstanding granularity of this feature and resulting simplifications for many real world use cases:

• Horizontal - You can selectively hide or expose specific DynamoDB items in a particular table by matching on hash key values
• Vertical - You can selectively hide or expose specific attributes of all of the DynamoDB items in a particular table by matching on attribute names
• Combined - You can exercise horizontal and vertical control in the same policy

See Fine-Grained Access Control for Amazon DynamoDB for further details on this ability to determine who can access individual data items and attributes in Amazon DynamoDB tables and indexes, and the actions that can be performed on them.

• This also includes a concrete example how to include the user id in the primary key of an Amazon DynamoDB table and hiding information both horizontally and vertically via an appropriate IAM Condition thereafter based on the calling user.

---

Addendum

The far reaching scope/impact of this new functionality is also stressed in Werner Vogels' Simplifying Mobile App Data Management with DynamoDB's Fine-Grained Access Control:

With Fine-Grained Access Control, we solve this problem by enabling you to author access policies that include conditions that describe additional levels of filtering and control. This eliminates the need for the proxy layer, simplifies the application stack, and results in cost savings.

[...]

With today’s launch, apps running on mobile devices can send workloads to a DynamoDB table, row, or even a column without going through an intervening proxy layer. [...] This capability allows apps running on mobile devices to modify only rows belonging to a specific user. Also, by consolidating users’ data in a DynamoDB table, you can obtain real-time insights over the user base, at large scale, without going through expensive joins and batch approaches such as scatter / gather.

Answer 3

I don't believe this is possible. IAM roles are basically controlling which API calls can a client make. Once the client get permission to perform an action, DynamoDB doesn't log that action and attach it to the client.

If you need this kind of behavior you should probably keep an attribute in your table that updates with some meta-data about the user made the operation.

Answer 4

I'm fairly sure that the answer to your question is yes. You'll probably have to use AWS Cognito with an IAM role policy behind it.

You might have to do some fiddling with this, but if you add a policy like the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:Scan",
                "dynamodb:UpdateItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:ap-southeast-2: NUMBER:table/myapplication_product"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "dynamodb:LeadingKeys": [
                        "${cognito-identity.amazonaws.com:sub}"
                    ]
                }
            }
        }
    ]
}

Firstly, this will restrict access to the dynamodb resource to just the methods named, but the "Condition" block will additionally restrict access to identities that match the hashkey that you are trying to alter - obviously, this doesn't affect the Scan (only the GetItem and UpdateItem). Now exactly how you match up those keys, is the fiddling that I referred to, but the solution is in there somewhere. Hope this helps.