DynamoDB - Access Control

DynamoDB uses the credentials you provide to authenticate requests. These credentials are required and must include permissions to access AWS resources. These permissions cover almost every aspect of DynamoDB down to minor operation or functionality.

Permission types

In this section, we will discuss the various permissions and resource access in DynamoDB.

User authentication

When you signed up, you provided a password and email address that serve as your root credentials. DynamoDB associates this data with your AWS account and uses it to provide full access to all resources.

AWS recommends that you use your root credentials only to create an administrator account. This allows you to create IAM accounts/users with lesser rights. IAM users are other accounts created with the IAM service. Their permissions/access privileges include access to protected pages and certain user permissions such as modifying a table.

Access keys provide another option for additional accounts and access. Use them to grant access, and to avoid manual granting in certain situations. Federated users provide another option by providing access through an identity provider.

administration

AWS resources remain the property of the account. Permission policies govern the permissions granted to spawn or access resources. Administrators associate permission policies with IAM identities, that is, with roles, groups, users, and services. They also attach permissions to resources.

Permissions specify users, resources, and actions. Please note that administrators are just accounts with administrative privileges.

Operation and resources

Tables remain the primary resource in DynamoDB. Subresources serve as additional resources, such as streams and indexes. These resources use unique names, some of which are listed in the following table:

Ownership

The resource owner is defined as the AWS account that originated the resource, or the primary entity account responsible for authenticating the request when the resource was created. Consider how it works in a DynamoDB environment −

• By using root credentials to create the table, your account remains the owner of the resource.

• When you create an IAM user and grant the user permission to create a table, your account remains the owner of the resource.

• When you create an IAM user and grant the user and anyone who can assume the role permission to create the table, your account remains the owner of the resource.

By using root credentials to create the table, your account remains the owner of the resource.

When you create an IAM user and grant the user permission to create a table, your account remains the owner of the resource.

When you create an IAM user and grant the user and anyone who can assume the role permission to create the table, your account remains the owner of the resource.

Resource access control

Access control basically requires attention to the permission policy that describes users and access to resources. You associate policies with IAM identities or resources. However, DynamoDB only supports IAM/identity policies.

Identity-based policies (IAM) allow you to grant privileges in the following ways:

• Attach permissions for users or groups.
• Attach permissions to roles for permissions between accounts.

Other AWS allow resource-based policies. These policies allow access to things like the S3 bucket.

Policy elements

Policies define actions, effects, resources and principles; and give permission to perform these operations.

Note. API operations may require permissions for multiple actions.

Take a closer look at the following policy elements −

• Resource - ARN identifies this.

• Action - The keywords identify these resource operations and allow or deny.

• Effect - It defines the effect for the user's action request, i.e. allow or deny with default denied.

• Principal − This identifies the user attached to the policy.

Resource - ARN identifies this.

Action - The keywords identify these resource operations and allow or deny.

Effect - It defines the effect for the user's action request, i.e. allow or deny with default denied.

Principal − This identifies the user attached to the policy.

terms

By granting permissions, you can specify conditions for when policies become active, such as on a specific date. Express conditions using condition keys, which include AWS system-wide keys and DynamoDB keys. These keys are discussed in detail later in the guide.

Console Permissions

The user requires certain basic permissions to use the console. They also require permission for the console in other standard services −

• cloud watch
• Data pipeline
• Identity and Access Management
• Notification Service
• lambda

If the IAM policy is too restrictive, the user cannot effectively use the console. Also, you don't have to worry about user rights for those who only call the CLI or API.

General rules for using Iam

AWS covers common operations in permissions with offline policies managed by IAM. They provide key permissions that allow you to avoid having to go deep into what you have to grant.

Some of them are the following:

• AmazonDynamoDBReadOnlyAccess - Provides read-only access through the console.

• AmazonDynamoDBFullAccess - Provides full access through the console.

• AmazonDynamoDBFullAccesswithDataPipeline - Provides full console access and allows export/import using Data Pipeline.

AmazonDynamoDBReadOnlyAccess - Provides read-only access through the console.

AmazonDynamoDBFullAccess - Provides full access through the console.

AmazonDynamoDBFullAccesswithDataPipeline - Provides full console access and allows export/import using Data Pipeline.

You can also create your own policies.

Granting Privileges: Using the Shell

You can grant permissions with a Javascript wrapper. The following program shows a typical permission policy −

{ "Version" : "2016-05-22" , "Statement" : [ { "Sid" : "DescribeQueryScanToolsTable" , "Effect" : "Deny" , 
     
     
       
           
           
         
         "Action" : [ "dynamodb:DescribeTable" , "dynamodb:Query" , "dynamodb:Scan" ], "Resource" : "arn:aws:dynamodb:us-west-2:account-id:table/Tools" } ] }  
             
             
             
          
           
       
    

You can view three examples:

Block the user from performing any table action.

{ "Version" : "2016-05-23" , "Statement" : [ { "Sid" : "AllAPIActionsOnTools" , "Effect" : "Deny" , "Action" : "dynamodb:*" , "Resource" : " arn:aws:dynamodb:us-west-2:155556789012:table/Tools" } ] } 
     
     
       
           
           
           
           
       
    

Block access to the table and its indexes.

{ "Version" : "2016-05-23" , "Statement" : [ { "Sid" : "AccessAllIndexesOnTools" , "Effect" : "Deny" , "Action" : [ "dynamodb:*" ], "Resource" : [ "arn:aws:dynamodb:us-west-2:155556789012:table/Tools" , "arn:aws:dynamodb:us-west-2:155556789012:table/Tools/index/*" ] } ] } 
     
     
       
           
           
          
             
          
           
             
             
          
       
    

Block the user from making a purchase of reserved capacity.

{ "Version" : "2016-05-23" , "Statement" : [ { "Sid" : "BlockReservedCapacityPurchases" , "Effect" : "Deny" , "Action" : "dynamodb:PurchaseReservedCapacityOfferings" , "Resource" : " arn:aws:dynamodb:us-west-2:155556789012:*" } ] } 
     
     
       
           
           
           
           
       
    

Granting Rights: Using the GUI Console

You can also use the GUI console to create IAM policies. To get started, select Tables from the navigation bar. In the list of tables, select the target table and do the following:

Step 1 − Select the Access Control tab .

Step 2 - Select a provider of identities, actions, and policy attributes. Select Create policy after entering all settings.

Step 3: Select Attach instructions to policy and complete each required step to associate the policy with the appropriate IAM role.