IAM policy for DynamoDB - Deep Dive

Overview - IAM policy for DynamoDB

What is it?

An IAM policy for DynamoDB is a set of rules that control who can do what with DynamoDB tables and data. It tells AWS which actions a user or service is allowed or denied on DynamoDB resources. These policies are written in JSON and attached to users, groups, or roles to manage access securely.

Why it matters

Without IAM policies, anyone could access or change your DynamoDB data, risking data loss or leaks. IAM policies protect your data by ensuring only authorized people or services can read, write, or manage your tables. This keeps your applications safe and reliable.

Where it fits

Before learning IAM policies, you should understand basic AWS concepts like users, roles, and permissions. After mastering IAM policies for DynamoDB, you can explore advanced security topics like encryption, fine-grained access control, and monitoring with AWS CloudTrail.

Mental Model

Core Idea

IAM policies for DynamoDB are like permission slips that say exactly who can do what with your database tables.

Think of it like...

Imagine a library where each book (DynamoDB table) has a lock, and only people with the right keys (IAM policies) can open certain books to read or write inside.

┌─────────────────────────────┐
│        IAM Policy           │
│  ┌───────────────┐          │
│  │  Effect: Allow│          │
│  │  Action:     │          │
│  │  - dynamodb:GetItem       │
│  │  - dynamodb:PutItem       │
│  │  Resource: Table ARN      │
│  └───────────────┘          │
└─────────────┬───────────────┘
              │
              ▼
      ┌─────────────────┐
      │ DynamoDB Table   │
      └─────────────────┘

Build-Up - 7 Steps

1

Foundation

What is an IAM Policy

Concept: IAM policies define permissions for AWS resources using JSON rules.

IAM policies are JSON documents that specify who can do what on which AWS resources. They have elements like Effect (Allow or Deny), Action (the operation), and Resource (the target). For example, a policy can allow a user to read items from a DynamoDB table.

Result

You understand that IAM policies control access by specifying permissions in a structured way.

Understanding IAM policies is the first step to controlling access securely in AWS.

2

Foundation

DynamoDB Basics for IAM

Concept: DynamoDB tables and actions are the targets of IAM policies.

DynamoDB is a database service with tables storing data. Common actions include GetItem (read), PutItem (write), and DeleteItem (remove). IAM policies specify these actions to allow or deny access to tables or indexes.

Result

You know the key DynamoDB actions and resources that IAM policies control.

Knowing DynamoDB actions helps you write precise policies that grant only needed permissions.

3

Intermediate

Writing Basic DynamoDB IAM Policies

🤔Before reading on: do you think a policy must list every action separately or can use wildcards? Commit to your answer.

Concept: Policies can specify exact actions or use wildcards to cover multiple actions.

You can write policies that allow specific actions like "dynamodb:GetItem" or use wildcards like "dynamodb:*" to allow all DynamoDB actions. It's safer to specify only needed actions. Also, you must specify the resource ARN to limit the policy to certain tables.

Result

You can create a policy that allows a user to read and write to a specific DynamoDB table.

Using precise actions and resources in policies reduces security risks by limiting access.

4

Intermediate

Using Condition Keys in Policies

🤔Before reading on: do you think conditions can restrict access by time or IP address? Commit to your answer.

Concept: IAM policies support conditions to add extra rules like time or source IP restrictions.

You can add a Condition block in a policy to restrict access. For example, you can allow DynamoDB actions only during business hours or from specific IP addresses. This adds an extra layer of security beyond just actions and resources.

Result

You can write policies that allow DynamoDB access only under certain conditions.

Conditions let you tailor access dynamically, improving security without changing user roles.

5

Intermediate

Fine-Grained Access Control with IAM

🤔Before reading on: do you think IAM policies can control access to individual items in a table? Commit to your answer.

Concept: IAM supports fine-grained control to restrict access to specific items or attributes in DynamoDB.

Using IAM policy variables and condition keys like dynamodb:LeadingKeys, you can allow users to access only items with certain partition keys. This means users see only their own data, not the whole table. This is important for multi-user applications.

Result

You can create policies that restrict users to their own data rows in DynamoDB.

Fine-grained control helps build secure multi-tenant apps by limiting data exposure.

6

Advanced

Combining IAM Roles and Policies for DynamoDB

🤔Before reading on: do you think roles can be assumed by services as well as users? Commit to your answer.

Concept: IAM roles let AWS services or users temporarily get permissions defined by policies.

Instead of attaching policies directly to users, you create roles with policies and let users or services assume these roles. For example, a Lambda function can assume a role with DynamoDB write permissions. This separates permissions from identities and improves security.

Result

You can design secure systems where services get only needed DynamoDB access via roles.

Using roles with policies enables flexible, least-privilege access patterns in production.

7

Expert

Policy Evaluation and Permission Boundaries

🤔Before reading on: do you think Deny always overrides Allow in IAM? Commit to your answer.

Concept: IAM evaluates all policies together, and explicit Deny always overrides Allow; permission boundaries limit maximum permissions.

When a request is made, AWS checks all policies attached to the user, group, and role. If any policy explicitly Denies an action, it is denied even if others Allow it. Permission boundaries set the maximum permissions a user or role can have, acting as a guardrail. This helps prevent privilege escalation.

Result

You understand how AWS decides if a DynamoDB action is allowed or denied in complex setups.

Knowing policy evaluation order and boundaries prevents accidental over-permission and security holes.

Under the Hood

IAM policies are JSON documents stored in AWS that the AWS authorization system evaluates at request time. When a user or service tries to access DynamoDB, AWS collects all relevant policies attached to that identity and resource. It merges them, checks for explicit Deny statements first, then Allow statements. Conditions are evaluated last to finalize the decision. This happens in milliseconds to allow or block the request.

Why designed this way?

AWS designed IAM policies to be flexible and scalable, supporting many users and services with different needs. The explicit Deny rule ensures security by preventing accidental permission grants. Using JSON makes policies easy to write, read, and automate. Alternatives like hard-coded permissions would be inflexible and error-prone.

┌───────────────┐
│ User/Service  │
└──────┬────────┘
       │ Request to DynamoDB
       ▼
┌─────────────────────┐
│ IAM Policy Engine    │
│ ┌───────────────┐   │
│ │ Collect Policies│  │
│ ├───────────────┤   │
│ │ Evaluate Deny  │◄──┤
│ │ Evaluate Allow │   │
│ │ Check Conditions│  │
│ └───────────────┘   │
└─────────┬───────────┘
          │ Decision
          ▼
┌─────────────────┐
│ DynamoDB Action │
│ Allowed or Denied│
└─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does an Allow in one policy override a Deny in another? Commit to yes or no.

Common Belief: If one policy allows an action, it will always be allowed even if another policy denies it.

Reality: Explicit Deny in any policy always overrides any Allow, blocking the action.

Why it matters: Ignoring Deny rules can lead to unexpected access failures or security holes if Deny is not respected.

Quick: Can you use IAM policies to restrict access to individual items in a DynamoDB table? Commit to yes or no.

Common Belief: IAM policies only control access at the table level, not at the item level.

Reality: IAM supports fine-grained access control to restrict access to specific items using condition keys.

Why it matters: Believing this limits your ability to secure multi-user applications properly.

Quick: Do you think IAM policies attached to a user automatically apply to AWS services the user runs? Commit to yes or no.

Common Belief: Policies attached to users automatically grant permissions to services they use, like Lambda functions.

Reality: Services need their own roles with policies; user policies do not transfer automatically.

Why it matters: Misunderstanding this can cause services to fail due to missing permissions.

Quick: Is it safe to use wildcards like "dynamodb:*" in production policies? Commit to yes or no.

Common Belief: Using wildcards is fine because it saves time and covers all needed actions.

Reality: Wildcards grant broad permissions and increase security risks; least privilege is best practice.

Why it matters: Overly broad permissions can lead to data leaks or accidental data loss.

Expert Zone

1

IAM policies can include variables that dynamically adjust permissions based on the request context, enabling highly flexible access control.

2

Permission boundaries act as a second layer of defense, limiting the maximum permissions even if a user or role has broader policies attached.

3

Combining IAM policies with resource-based policies on DynamoDB tables allows for complex trust relationships and cross-account access.

When NOT to use

IAM policies are not suitable for encrypting data or controlling access inside the data itself; use DynamoDB encryption and application-level controls instead. For very complex attribute-level access, consider using AWS Lake Formation or custom application logic.

Production Patterns

In production, teams use IAM roles for services like Lambda or EC2 to access DynamoDB with minimal permissions. They apply fine-grained access control to isolate user data and use permission boundaries to prevent privilege escalation. Policies are version-controlled and tested before deployment.

Connections

Role-Based Access Control (RBAC)

IAM policies implement RBAC by assigning permissions to roles that users or services assume.

Understanding RBAC helps grasp how IAM policies group permissions logically for easier management.

Encryption

IAM policies control who can access data, while encryption protects data confidentiality even if access is gained.

Knowing the difference between access control and encryption helps build layered security for DynamoDB.

Legal Contracts

IAM policies are like contracts specifying allowed actions and restrictions between parties.

Seeing policies as contracts clarifies why explicit Deny clauses are critical to enforce rules strictly.

Common Pitfalls

#1 Granting overly broad permissions with wildcards.

Wrong approach:

{
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "*"
}

Correct approach:

{
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
"Resource": "arn:aws:dynamodb:region:account-id:table/TableName"
}

Root cause:

Misunderstanding the principle of least privilege and convenience over security.

#2 Attaching policies only to users and expecting services to inherit permissions.

Wrong approach:

User policy grants DynamoDB access but Lambda function has no role or policy.

Correct approach:

Create an IAM role with DynamoDB permissions and assign it to the Lambda function.

Root cause:

Confusing user permissions with service roles and how AWS delegates permissions.

#3 Not specifying resource ARNs, leading to unintended access.

Wrong approach:

{
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": "*"
}

Correct approach:

{
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": "arn:aws:dynamodb:region:account-id:table/TableName"
}

Root cause:

Lack of understanding of resource scoping in IAM policies.

Key Takeaways

IAM policies are JSON rules that control who can do what with DynamoDB tables and data.

Explicit Deny always overrides Allow, ensuring strict security enforcement.

Fine-grained access control lets you restrict users to specific items or attributes in DynamoDB.

Using roles with policies is best practice for granting permissions to AWS services securely.

Least privilege and precise resource specification reduce security risks in production.

Practice

1. What does the Action element specify in an IAM policy for DynamoDB?

easy

A. The allowed or denied DynamoDB operations

B. The AWS region where the table is located

C. The encryption method used by the table

D. The billing mode of the DynamoDB table

Solution

1. Step 1: Understand the role of Action in IAM policies

   The Action element defines which DynamoDB operations (like read, write) are allowed or denied.

2. Step 2: Differentiate from other policy elements

   Other elements like Resource specify the table, but Action controls what can be done.

3. Final Answer:

   The allowed or denied DynamoDB operations -> Option A

4. Quick Check:

   Action = Allowed/Deny operations [OK]

Hint: Action controls what operations are allowed or denied [OK]

Common Mistakes:

• Confusing Action with Resource
• Thinking Action specifies table location
• Mixing Action with encryption or billing settings

2. Which of the following is the correct syntax to specify a DynamoDB table resource ARN in an IAM policy?

easy

A. "Resource": "arn:aws:s3:::mybucket"

B. "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable"

C. "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table"

D. "Resource": "arn:aws:dynamodb:us-east-1:123456789012:database/MyTable"

Solution

1. Step 1: Identify correct ARN format for DynamoDB table

   The ARN format for a DynamoDB table is: arn:aws:dynamodb:<region>::table/.

2. Step 2: Compare options to the correct format

   "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" matches the correct format exactly. "Resource": "arn:aws:s3:::mybucket" is for S3, C misses table name, D uses wrong resource type.

3. Final Answer:

   "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" -> Option B

4. Quick Check:

   Resource ARN for DynamoDB table = "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" [OK]

Hint: DynamoDB table ARN ends with 'table/YourTableName' [OK]

Common Mistakes:

• Using S3 ARN format instead of DynamoDB
• Omitting the table name in ARN
• Using 'database' instead of 'table' in ARN

3. Given this IAM policy snippet, what DynamoDB actions are allowed?

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query"],
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}

medium

A. Full access to all DynamoDB tables

B. Writing and deleting items in the Orders table

C. Only reading items from the Orders table

D. No access because the policy is incomplete

Solution

1. Step 1: Analyze the Action list in the policy

   The policy allows only "dynamodb:GetItem" and "dynamodb:Query", which are read operations.

2. Step 2: Check the Resource and Effect

   The resource is the Orders table only, and Effect is Allow, so only reading from Orders is allowed.

3. Final Answer:

   Only reading items from the Orders table -> Option C

4. Quick Check:

   Allowed actions = GetItem and Query (read) [OK]

Hint: GetItem and Query mean read-only access [OK]

Common Mistakes:

• Assuming write or delete permissions are included
• Thinking policy applies to all tables
• Ignoring the Effect value

4. You wrote this IAM policy but it does not allow any access to your DynamoDB table. What is the error?

{
  "Effect": "Allow",
  "Action": "dynamodb:PutItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table"
}

medium

A. Resource ARN is incomplete; missing table name

B. Action should be an array, not a string

C. Effect should be Deny to allow access

D. Policy is missing a Condition block

Solution

1. Step 1: Check the Resource ARN format

   The ARN ends with 'table' but does not specify the table name, so it does not point to any specific table.

2. Step 2: Understand impact of incomplete ARN

   Without a full ARN including the table name, the policy does not grant access to any resource.

3. Final Answer:

   Resource ARN is incomplete; missing table name -> Option A

4. Quick Check:

   Resource ARN must include table name [OK]

Hint: Resource ARN must specify full table name [OK]

Common Mistakes:

• Thinking Action must be an array always
• Confusing Effect Allow with Deny
• Assuming Condition is required for access

5. You want to create an IAM policy that allows a user to read from any DynamoDB table in your account but only write to a specific table named 'Inventory'. Which policy setup is correct?

hard

A. { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }, { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" }

B. { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }

C. { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" }

D. { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }, { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" }

Solution

1. Step 1: Identify read permissions scope

   Read actions (GetItem, Query) should apply to all tables, so Resource uses wildcard '*'.

2. Step 2: Identify write permissions scope

   Write action (PutItem) is limited to the 'Inventory' table only.

3. Step 3: Match policy statements to requirements

   { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }, { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" } correctly separates read and write permissions with proper Resource ARNs.

4. Final Answer:

   Separate statements: read on all tables, write only on Inventory -> Option D

5. Quick Check:

   Read = all tables, Write = Inventory only [OK]

Hint: Use separate statements for different resource scopes [OK]

Common Mistakes:

• Granting write access to all tables
• Mixing read and write on wrong resources
• Using wildcard for write when not intended