Condition keys for row-level security in DynamoDB - Step-by-Step Execution

Concept Flow - Condition keys for row-level security

Request arrives

↓

Evaluate Condition Keys

↓

Match user attributes with item attributes?

Yes No↓

Allow access

↓

Return data or error

When a request comes, DynamoDB checks condition keys to see if the user can access each row. If the user's attributes match the row's attributes, access is allowed; otherwise, it is denied.

Execution Sample

DynamoDB

Condition:
  "dynamodb:LeadingKeys": ["${www.example.com:user_id}"]

This condition allows access only to rows where the partition key matches the user's ID.

Execution Table

Step	Request User ID	Row Partition Key	Condition Check	Access Decision
1	user123	user123	user123 == user123	Allow
2	user123	user456	user123 == user456	Deny
3	user789	user789	user789 == user789	Allow
4	user789	user123	user789 == user123	Deny
5	-	-	-	Stop: No more rows

💡 Execution stops after checking all rows for matching user IDs.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	Final
Request User ID	user123	user123	user123	user789	user789	-
Row Partition Key	user123	user456	user789	user789	user123	-
Condition Result	N/A	True	False	True	False	-
Access Decision	N/A	Allow	Deny	Allow	Deny	-

Key Moments - 2 Insights

Why does access get denied when the user ID and partition key don't match?

Because the condition key requires the user's ID to match the row's partition key exactly, as shown in execution_table rows 2 and 4 where the condition check is false, so access is denied.

What happens if the condition key is missing or incorrect?

If the condition key is missing or does not match, DynamoDB denies access by default to protect data, ensuring no unauthorized row-level access occurs.

Visual Quiz - 3 Questions

Look at the execution table, what is the access decision at step 3?

A Error

B Deny

C Allow

D Unknown

💡 Hint

Check the 'Access Decision' column at step 3 in the execution_table.

At which step does the condition check fail for user123?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Condition Check' column for user123 in the execution_table.

If the request user ID changes to 'user456', what would happen at step 1?

A Access allowed for row with partition key 'user123'

B Access denied for row with partition key 'user123'

C Access allowed for all rows

D Access denied for all rows

💡 Hint

Compare the condition check logic where user ID must match the row partition key.

Concept Snapshot

Condition keys in DynamoDB control row-level access.
They compare user attributes (like user ID) with item keys.
Access is allowed only if the condition matches.
If no match, access is denied to protect data.
Use "dynamodb:LeadingKeys" for partition key checks.

Full Transcript

When a request comes to DynamoDB, it checks condition keys to decide if the user can access each row. The key condition is usually that the user's ID matches the row's partition key. If they match, access is allowed; if not, access is denied. This ensures users only see their own data. The execution table shows examples where user IDs and partition keys are compared step-by-step, resulting in allow or deny decisions. If the condition key is missing or incorrect, DynamoDB denies access by default to keep data safe.

Practice

1. What is the main purpose of using Condition Keys in DynamoDB for row-level security?

easy

A. To encrypt data at rest in the database

B. To speed up query performance by indexing rows

C. To backup data automatically to another region

D. To control access by checking each row's attribute against user values

Solution

1. Step 1: Understand Condition Keys role

   Condition keys are used to compare row data with user attributes to decide access.

2. Step 2: Identify main purpose

   This comparison controls which rows a user can read or write, ensuring security.

3. Final Answer:

   To control access by checking each row's attribute against user values -> Option D

4. Quick Check:

   Condition keys = control access per row [OK]

Hint: Condition keys compare row data to user info for access [OK]

Common Mistakes:

• Confusing condition keys with indexing
• Thinking condition keys handle encryption
• Assuming condition keys backup data

2. Which of the following is the correct syntax to use a condition key in a DynamoDB policy to allow access only if the userId attribute matches the requester's ID?

easy

A. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}

B. "Condition": {"StringEquals": {"dynamodb:Attributes.userId": "${aws:userid}"}}

C. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:username}"}}

D. "Condition": {"StringEquals": {"dynamodb:Attributes.userId": "${aws:username}"}}

Solution

1. Step 1: Identify correct condition key for partition key

   "dynamodb:LeadingKeys" is used to check the partition key value in policies.

2. Step 2: Match with user ID variable

   "${aws:userid}" is the correct variable for the requester's user ID.

3. Final Answer:

   "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}} -> Option A

4. Quick Check:

   LeadingKeys with aws:userid = correct syntax [OK]

Hint: Use dynamodb:LeadingKeys for partition key in condition [OK]

Common Mistakes:

• Using dynamodb:Attributes instead of LeadingKeys for partition key
• Mixing aws:username with userId variable
• Incorrect JSON structure in condition

3. Given a DynamoDB table with partition key userId and a policy condition: "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "123"}}, what will happen if a user with ID 123 tries to read a row with userId = 123?

medium

A. Access is allowed because the condition matches the partition key

B. Access is denied because the condition only checks sort keys

C. Access is allowed for all rows regardless of userId

D. Access is denied because the condition key is invalid

Solution

1. Step 1: Understand the condition key usage

   The condition checks if the partition key (userId) equals "123".

2. Step 2: Match user ID with row key

   The user ID is "123" and the row's userId is also "123", so condition passes.

3. Final Answer:

   Access is allowed because the condition matches the partition key -> Option A

4. Quick Check:

   Matching LeadingKeys value = access allowed [OK]

Hint: Condition matches partition key value means access allowed [OK]

Common Mistakes:

• Thinking condition checks sort key only
• Assuming condition key is invalid syntax
• Believing access is always denied without extra permissions

4. You wrote this condition in your DynamoDB policy: "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}. But users report they cannot access their own rows. What is the likely problem?

medium

A. The variable ${aws:userid} is incorrect; it should be ${aws:username}

B. The condition key dynamodb:LeadingKeys only works with sort keys, not partition keys

C. The variable ${aws:userid} might not match the actual partition key values stored

D. The policy is missing the action permission for reading items

Solution

1. Step 1: Check variable correctness

   ${aws:userid} is a valid variable but must match stored partition key values exactly.

2. Step 2: Consider data mismatch

   If stored userId values differ in format or case, condition fails and denies access.

3. Final Answer:

   The variable ${aws:userid} might not match the actual partition key values stored -> Option C

4. Quick Check:

   Mismatch between variable and stored keys = access denied [OK]

Hint: Ensure variable matches stored partition key exactly [OK]

Common Mistakes:

• Assuming aws:userid is always wrong
• Confusing partition and sort keys in condition
• Ignoring missing action permissions

5. You want to enforce row-level security so that users can only update their own items in a DynamoDB table with partition key userId and sort key itemId. Which condition key setup correctly enforces this in an IAM policy?

hard

A. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}

B. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": ["${aws:userid}", "${aws:itemid}"]}}

C. "Condition": {"StringEquals": {"dynamodb:Attributes.userId": "${aws:userid}", "dynamodb:Attributes.itemId": "${aws:itemid}"}}

D. "Condition": {"ForAllValues:StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}

Solution

1. Step 1: Understand table keys

   Partition key userId determines ownership; sort key itemId identifies specific items within a user's partition.

2. Step 2: Identify correct condition

   StringEquals on dynamodb:LeadingKeys with an array of [${aws:userid}, ${aws:itemid}] checks both partition and sort keys match, enforcing row-level security for specific items.

3. Final Answer:

   "Condition": {"StringEquals": {"dynamodb:LeadingKeys": ["${aws:userid}", "${aws:itemid}"]}} -> Option B

4. Quick Check:

   StringEquals dynamodb:LeadingKeys with array = partition and sort key match [OK]

Hint: Use array in dynamodb:LeadingKeys to match partition and sort keys [OK]

Common Mistakes:

• Using dynamodb:Attributes for primary key value checks
• Applying ForAllValues:StringEquals which mismatches sort key
• Using single string instead of array for both keys