lambda - Serverless Framework dynamobd iamRoleStatements modify -> AccessDeniedException

Question

I've inherited an API that uses ddb. Unfortunately, everything is being done on one production table. I am in the process of completing a development setup, so we don't have to experiment on the production table. As it turns out, the new data is much cleaner and our client wants to use it instead. I figured, I could simply update the Resource block of our ddb config to point to the new ddb table resource arn but that's when I ran into trouble.

Part of the config looks like this:

...  
iamRoleStatements:
  - Effect: Allow
    Action:
      - dynamodb:DescribeTable
      - dynamodb:Query
      - dynamodb:Scan
      - dynamodb:GetItem
      - dynamodb:PutItem
      - dynamodb:UpdateItem
      - dynamodb:DeleteItem
    Resource:
      - "arn:aws:dynamodb:us-east-1:*:table/${self:provider.environment.PROD_TABLE}"

At first, I simply updated the Resource block to the value below and deployed

 - "arn:aws:dynamodb:us-east-1:*:table/${self:provider.environment.DEV_TABLE}"

After the deploy I received this (redacted) error in CloudWatch:

AccessDeniedException: User: arn:aws:sts::<redacted>:assumed-role/... is not authorized to perform: dynamodb:DescribeTable on resource: arn:aws:dynamodb:us-east-1<redacted>/PROD_TABLE

Note, the arn:aws:dynamodb resource (above) is referencing the old table

A re-deploy does not update the resource for the newly created assumed (lambda) role. I am not sure how to make this happen without a "remove" and "deploy."

Forgoing an exact solution is there an easier way to switch over to a different ddb without causing any major disruption to our users?

question from:https://stackoverflow.com/questions/65947745/serverless-framework-dynamobd-iamrolestatements-modify-accessdeniedexception

Answer 1

Based in what I can see in the log

AccessDeniedException: User: arn:aws:sts:::assumed-role/... is not authorized to perform: dynamodb:DescribeTable on resource: arn:aws:dynamodb:us-east-1/PROD_TABLE

The configuration has worked as the user now does not have permissions to describeTable over the old table (PROD_TABLE). Probably somewhere in the code you are still trying to work with the old table instead of the new one.

If you still need this you can give the role permissions for both tables:

iamRoleStatements: 
   - Effect: Allow
     Action:
         - dynamodb:DescribeTable
         - dynamodb:Query
         - dynamodb:Scan
         - dynamodb:GetItem
         - dynamodb:PutItem
         - dynamodb:UpdateItem
         - dynamodb:DeleteItem
     Resource:
         - "arn:aws:dynamodb:us-east-1:*:table/${self:provider.environment.PROD_TABLE}"
         - "arn:aws:dynamodb:us-east-1:*:table/${self:provider.environment.ENV_TABLE}"