DynamoDB IAM policy constraints and STS credential expiry symptoms

Direct answer

Expired STS token failures appear in CloudTrail data‑plane logs with errorCode="ExpiredToken" (or "TokenExpired"), while genuine permission denials show errorCode="AccessDeniedException". Tenant isolation using condition keys like dynamodb:LeadingKeys remains viable for GetItem, BatchGetItem and Query, but not for Scan; when you need sort‑key restrictions, attribute‑level conditions, or differing permissions across multiple tables/indexes, move the logic to the application layer. To verify that a least‑privilege policy correctly constrains Query and Scan, run the IAM policy simulator with the specific actions and resource ARNs, then validate with live calls using temporary STS credentials and check CloudTrail data events for the expected success or denial codes.

Confirmed facts (from research)

• CloudTrail data‑plane logs for DynamoDB include errorCode fields: ExpiredToken/TokenExpired for expired STS tokens and AccessDeniedException for missing permissions.
• The condition key dynamodb:LeadingKeys is supported for GetItem, BatchGetItem and Query, but not for Scan.
• When policy complexity requires sort‑key constraints, attribute‑level conditions, or varied permissions across multiple tables/indexes, isolation should be handled in the application layer.
• Verification steps: enable CloudTrail data events for DynamoDB, use the IAM policy simulator (aws iam simulate-principal-policy), then test with valid and expired STS tokens and inspect CloudTrail for the appropriate error codes.

Likely explanation & steps for this case

1. Enable data‑plane logging – Ensure CloudTrail is configured to capture DynamoDB data events (management console → CloudTrail → Data events → add the DynamoDB table ARN or use an S3 bucket/log group). Without this, you cannot distinguish token expiry from access denials.
2. Test with a valid STS token – Perform a GetItem or Query call; verify the response is Success and CloudTrail shows no errorCode (or errorCode="None").
3. Test with an expired token – Use the same role but supply an expired token; the call should fail and CloudTrail must record errorCode="ExpiredToken" (or "TokenExpired") with a message about the security token being expired.
4. Test a policy denial – Attempt an action not permitted by the role (e.g., PutItem on a table the role lacks); CloudTrail should show errorCode="AccessDeniedException" and a message about missing permissions.
5. Validate Scan behavior – Because dynamodb:LeadingKeys does not apply to Scan, run a Scan request that should be allowed by the policy; if you observe unexpected denials, add a filter expression or enforce the partition‑key check in application code.
6. Use the IAM policy simulator – Run:

   aws iam simulate-principal-policy \
         --policy-source-arn arn:aws:iam:::role/ \
         --action-names dynamodb:Query dynamodb:Scan \
         --resource-arns arn:aws:dynamodb:::table/ \
         --context-entries Key='dynamodb:LeadingKeys',Values='',Type='boolean'
       

   Examine the evaluation results; they should show "allowed" for the intended tenant and "denied" for others.

Missing diagnostic detail

If CloudTrail data events for DynamoDB are not already enabled, the above steps cannot be performed. Please confirm whether data‑plane logging is active for the relevant DynamoDB tables; if not, enable it before proceeding with the validation steps.