Menu
Amazon DynamoDB
Developer Guide (API Version 2012-08-10)

DAX Access Control

DAX is designed to work together with DynamoDB, to seamlessly add a caching layer to your applications. However, DAX and DynamoDB are separate AWS services. Even though both services use AWS Identity and Access Management (IAM) to implement their respective security policies, the security models for DAX and DynamoDB are different.

We highly recommend that you understand both security models, so that you can implement proper security measures for your applications that use DAX.

In this section, we describe the access control mechanisms provided by DAX, and provide sample IAM policies that you can tailor to your needs.

With DynamoDB, you can create IAM policies that limit the actions a user can perform on individual DynamoDB resources. For example, you can create a user role that only allows the user to perform read-only actions on a particular DynamoDB table. (For more information, see Authentication and Access Control for Amazon DynamoDB.) By comparison, the DAX security model focuses on cluster security, and the ability of the cluster to perform DynamoDB API actions on your behalf.

Warning

If you are currently using IAM roles and policies to restrict access to DynamoDB tables data, then the use of DAX can subvert those policies. For example, a user could have access to a DynamoDB table via DAX but not have explicit access to the same table accessing DynamoDB directly. (For more information, see Authentication and Access Control for Amazon DynamoDB.)

DAX does not enforce user-level separation on data in DynamoDB. Instead, users inherit the permissions of the DAX cluster's IAM policy when they access that cluster. Thus, when accessing DynamoDB tables via DAX, the only access controls that are in effect are the permissions in the DAX cluster's IAM policy. No other permissions are recognized.

If you require isolation, we recommend that you create additional DAX clusters and scope the IAM policy for each cluster accordingly. For example, you could create multiple DAX clusters and allow each cluster to access only a single table.

IAM Service Role for DAX

When you create a DAX cluster, you must associate the cluster with an IAM role. This is known as the service role for the cluster.

Suppose that you wanted to create a new DAX cluster named DAXCluster01. You could create a service role named DAXServiceRole, and associate the role with DAXCluster01. The policy for DAXServiceRole would define the DynamoDB actions that DAXCluster01 could perform, on behalf of the users who interact with DAXCluster01.

When you create a service role, you must specify a trust relationship between DAXServiceRole and the DAX service itself. A trust relationship determines which entities can assume a role and make use of its permissions. The following is an example trust relationship document for DAXServiceRole:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dax.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

This trust relationship allows a DAX cluster to assume DAXServiceRole and perform DynamoDB API calls on your behalf.

The DynamoDB API actions that are allowed are described in an IAM policy document, which you attach to DAXServiceRole. The following is an example policy document:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DaxAccessPolicy", "Effect": "Allow", "Action": [ "dynamodb:*" ], "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books" ] } ] }

This policy allows DAX to perform all DynamoDB API actions on a DynamoDB table named Books, which is in the us-west-2 region and is owned by AWS account ID 123456789012.

IAM Policy to Allow DAX Cluster Access

Once you have created a DAX cluster, you need to grant permissions to an IAM user so that the user can access the DAX cluster.

For example, suppose you want to grant access to DAXCluster01 to an IAM user named Alice. You would first create an IAM policy (AliceAccessPolicy) that defines the DAX clusters and DAX API actions that the recipient can access. You would then confer access by attaching this policy to user Alice.

The following policy document gives the recipient full access on DAXCluster01:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "dax:*" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ] } ] }

The policy document allows access to the DAX cluster, but it does not grant any DynamoDB permissions. (The DynamoDB permissions are conferred by the DAX service role.)

For user Alice, you would first create AliceAccessPolicy with the policy document shown above. You would then attach the policy to Alice.

Note

Instead of attaching the policy to an IAM user, you could attach it to an IAM role. That way, all of the users who assume that role would have the permissions that you defined in the policy.

The user policy, in conjunction with the DAX service role, determine the DynamoDB resources and API actions that the recipient can access via DAX.

Case Study: Accessing DynamoDB and DAX

To help further your understanding of IAM policies for use with DAX, we present a common scenario. (We will refer to this scenario throughout the rest of this section.) The following diagram shows a high-level overview of the scenario:

In this scenario, there are the following entities:

  • An IAM user (Bob).

  • An IAM role (BobUserRole). Bob assumes this role at runtime.

  • An IAM policy (BobAccessPolicy). This policy is attached to BobUserRole. BobAccessPolicy defines the DynamoDB and DAX resources that BobUserRole is allowed to access.

  • A DAX cluster (DAXCluster01).

  • An IAM service role (DAXServiceRole). This role allows DAXCluster01 to access DynamoDB.

  • An IAM policy (DAXAccessPolicy). This policy is attached to DAXServiceRole. DAXAccessPolicy defines the DynamoDB APIs and resources that DAXCluster01 is allowed to access.

  • A DynamoDB table (Books).

The combination of policy statements in BobAccessPolicy and DAXAccessPolicy determine what Bob can do with the Books table. For example, Bob might be able to access Books directly (using the DynamoDB endpoint), indirectly (using the DAX cluster), or both. Bob might also be able to read data from Books, write data to Books, or both.

Access to DynamoDB, But No Access With DAX

It is possible to allow direct access to a DynamoDB table, while preventing indirect access using a DAX cluster. For direct access to DynamoDB, the privileges for BobUserRole are determined by BobAccessPolicy (which is attached to the role).

Read-Only Access to DynamoDB (Only)

Bob can access DynamoDB with BobUserRole. The IAM policy attached to this role (BobAccessPolicy) determines the DynamoDB tables that BobUserRole can access, and what APIs that BobUserRole can invoke.

Consider the following policy document for BobAccessPolicy:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

When this document is attached to BobAccessPolicy, it allows BobUserRole to access the DynamoDB endpoint and perform read-only operations on the Books table.

DAX does not appear in this policy, so access via DAX is denied.

Read-Write Access to DynamoDB (Only)

If BobUserRole requires read-write access to DynamoDB, the following policy would work:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Again, DAX does not appear in this policy, so access via DAX is denied.

Access to DynamoDB and to DAX

To allow access to a DAX cluster, you must include DAX-specific actions in an IAM policy.

The following DAX-specific actions correspond to their similarly-named counterparts in the DynamoDB API:

  • dax:GetItem

  • dax:BatchGetItem

  • dax:Query

  • dax:Scan

  • dax:PutItem

  • dax:UpdateItem

  • dax:DeleteItem

  • dax:BatchWriteItem

In addition, there are four other DAX-specific actions that do not correspond to any DynamoDB APIs:

  • dax:DefineAttributeList

  • dax:DefineAttributeListId

  • dax:DefineKeySchema

  • dax:Endpoints

You must specify all four of these actions in any IAM policy that allows access to a DAX cluster. These actions are specific to the low-level DAX data transport protocol. Your application does not need to concern itself with these actions—they are only used in IAM policies.

Read-Only Access to DynamoDB and Read-Only Access to DAX

Suppose that Bob requires read-only access to the Books table, from DynamoDB and from DAX. The following policy (attached to BobUserRole) would confer this access:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:DefineAttributeList", "dax:DefineAttributeListId", "dax:DefineKeySchema", "dax:Endpoints" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

The policy has a statement for DAX access (DAXAccessStmt) and another statement for DynamoDBaccess (DynamoDBAccessStmt). These statements would allow Bob to send GetItemBatchGetItemQuery, and Scan requests to DAXCluster01.

However, the service role for DAXCluster01 would also require read-only access to the Books table in DynamoDB. The following IAM policy, attached to DAXServiceRole, would fulfill this requirement:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Read-Write Access to DynamoDB and Read-Only with DAX

For a given user role, you can provide read-write access to a DynamoDB table, while also allowing read-only access via DAX.

For Bob, the IAM policy for BobUserRole would need to allow DynamoDB read and write actions on the Books table, while also supporting read-only actions via DAXCluster01.

The following example policy document for BobUserRole would confer this access:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:DefineKeySchema", "dax:DefineAttributeList", "dax:DefineAttributeListId", "dax:Endpoints" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

In addition, DAXServiceRole would require an IAM policy that allows DAXCluster01 to perform read-only actions on the Books table:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Read-Write Access to DynamoDB and Read-Write Access to DAX

Now suppose that Bob required read-write access to the Books table, directly from DynamoDB or indirectly from DAXCluster01. The following policy document, attached to BobAccessPolicy, would confer this access:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:DefineKeySchema", "dax:DefineAttributeList", "dax:DefineAttributeListId", "dax:Endpoints" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

In addition, DAXServiceRole would require an IAM policy that allows DAXCluster01 to perform read-write actions on the Books table:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

Access to DynamoDB Via DAX, But No Direct Access to DynamoDB

In this scenario, Bob can access the Books table via DAX, but he does not have direct access to the Books table in DynamoDB. Thus, when Bob gains access to DAX, he also gains access to a DynamoDB table that he otherwise might not be able to access. When you are configuring an IAM policy for the DAX service role, remember that any user that is given access to the DAX cluster via the user access policy will gain access to the tables specified in that policy. In this case, BobAccessPolicy gains access to the tables specified in DAXAccessPolicy.

If you are currently using IAM roles and policies to restrict access to DynamoDB tables and data, then the use of DAX can subvert those policies. In the policy below, Bob has access to a DynamoDB table via DAX but does not have explicit direct access to the same table in DynamoDB.

The following policy document (BobAccessPolicy), attached to BobUserRole, would confer this access:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:DefineKeySchema", "dax:DefineAttributeList", "dax:DefineAttributeListId", "dax:Endpoints" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" } ] }

Note that in this access policy, there are no permissions to access DynamoDB directly.

Together with BobAccessPolicy, the following DAXAccessPolicy would give BobUserRole access to the DynamoDB table Books even though BobUserRole cannot directly access the Books table:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }

As shown in this example, when you configure access control for the user access policy and the DAX cluster access policy, you must fully-understand the end-to-end access to ensure that the principle of least privilege is observed. You must also ensure that giving a user access to a DAX cluster does not subvert previously established access control policies.