By using AWS re:Post, you agree to the Terms of Use
/Getting an AccessDeniedException when trying to access (read) a DynamoDB table from a completely different AWS account/

Getting an AccessDeniedException when trying to access (read) a DynamoDB table from a completely different AWS account

0

Hello, I have an application deployed in an EKS cluster in Account A that is trying to read an item from a DynamoDB table in Account B. I have done the following :

  • I have created a role in Account B called DynDBReadAccess with a policy that allows someone to perform the dynamodb:GetItem action on the table arn:aws:dynamodb:us-east-1:<Account B>:table/myTable.

  • I then created the role CrossAccountDynDBAccess in Account A with permissions to perform the sts:AssumeRole action and assume the role arn:aws:iam::<Account B>:role/DynDBReadAccess.

  • I updated the trust policy in the DynDBReadAccess role to trust the Principal arn:aws:iam::<Account A>:role/CrossAccountDynDBAccess.

I have a pod with aws cli deployed in the cluster for debugging purposes. Now, I do the following.

  • I exec into the pod and run aws sts get-caller-identity, I see the correct assumed role CrossAccountDynDBAccess.
  • Then I run aws sts assume-role --role-arn "arn:aws:iam::<Account B>:role/DynDBReadAccess" --role-session-name crossAccountSession and I get the temporary credentials.
  • I set the environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN with the temporary credentials I just received.
  • I run the following command aws dynamodb get-item --table-name myTable --key 'somekey' and I get the following error

An error occurred (AccessDeniedException) when calling the GetItem operation: User: arn:aws:sts::<Account B>:assumed-role/DynDBReadAccess/crossAccountSession is not authorized to perform: dynamodb:GetItem on resource: arn:aws:dynamodb:ap-southeast-1:<Account B>:table/myTable

I thought that once the roles, permissions and trust policies were set, cross account access should be possible. Can someone tell me what is missing?

Some other points to note

  • The OIDC endpoint and IRSA role has been enabled in the EKS cluster and the service account for the cluster has been created.
  • The aws cli pod that I deployed has been deployed with the service account mapped to the IRSA role.
  • I tried doing the same thing with a lambda function where I created a lambda function in Account A that will read an item from the same DynamoDB table. The execution role of the lambda function assumes the arn:aws:iam::<Account B>:role/DynDBReadAccess and reads an item from the same DynamoDB table. This works.
1 Answers
0

Hi,

Reading your post, I see you call out two separate regions.

The IAM policy calls out us-east-1

I have created a role in Account B called DynDBReadAccess with a policy that allows someone to perform the dynamodb:GetItem action on the table arn:aws:dynamodb:us-east-1:<Account B>:table/myTable.

You then follow that with the error message, showing ap-southeast-1

An error occurred (AccessDeniedException) when calling the GetItem operation: User: arn:aws:sts::<Account B>:assumed-role/DynDBReadAccess/crossAccountSession is not authorized to perform: dynamodb:GetItem on resource: arn:aws:dynamodb:ap-southeast-1:<Account B>:table/myTable

This suggests that maybe your IAM policy or CLI tools are referencing the incorrect region. Based on this, can you confirm the location of the DynamoDB table and that your IAM policy (first quote, showing "us-east-1") is indeed matching the true location for the table.

Other things that you might want to check, but are less likely.

  1. You check the caller identity before you set the environment variables to assume the role. It might be worth doing this after (but before the DynamoDB call) to debug the situation, to ensure the environment variables are applying correctly

  2. Provide the CLI tools with a region like "--region us-east-1". This will likely be required if you table is in a different region to EC2/EKS.

I hope this helps.

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions