Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Step functions cross account access to DynamoDB

Just wondering if anyone has done encountered the following use case:

  • Account A has a step functions state machine
  • Account B has a DynamoDB table
  • Allow the state machine from Account A to PutItem into DynamoDB table in Account B

I know if we use Lambda with step functions, it allows resource based policies and we can allow "Principal" in Lambda as the state machine arn from another account and execute the lambda function in Account B from a state machine in Account A.

But DynamoDB does not support resource based policies, is there a way to deploy a CloudFormation template where we create a DynamoDB table with a policy/permission that allows a state machine from another Account PutItem in it?

like image 444
user3440027 Avatar asked Sep 04 '20 12:09

user3440027


People also ask

Can Lambda Access DynamoDB in another account?

In this scenario, Lambda functions and Amazon Elastic Compute Cloud (Amazon EC2) instances can access DynamoDB. If resources in a different AWS account try to access DynamoDB, they require setting up cross-account access and a trust relationship.

How can I configure a Lambda function to assume a role from another AWS account?

Configure your Lambda function's execution role to allow the function to assume an IAM role in another AWS account. Modify your cross-account IAM role's trust policy to allow your Lambda function to assume the role. Add the AWS Security Token Service (AWS STS) AssumeRole API call to your Lambda function's code.

Does DynamoDB support cross region replication?

Amazon DynamoDB now supports cross-region replication, a new feature that automatically replicates DynamoDB tables across AWS regions.


1 Answers

You have the gist of it, but are missing a small element that makes it possible.

Account A - contains:
    Lambda that is part of a State Machine
    Role A

Account B - Contains:
    DynamoDb
    Role B

You set up the lambda with Role A. You give Role A policy to assume Role B - you are not giving Role A any dynamo permissions, nor setting any resource based permisisons on the Dyanmo

You set up Role B with the ability to be assumed by Role A, and with DynamoDB access permissions.

You can now assume role B using your SDK of choice (sts) and resolve the security credentials, store them, and use them for your DynamoDB sdk calls inside your lambda in account A.

This is entirely possible, but one of the major drawbacks is that you have to be pretty explicit with cross account role arns - and if one side changes their arns, the system breaks. It is safer (and better in some ways) to set up an API with some basic CRUD operations to the Dynamo, and have the other account call it - unless you're trying to shave miliseconds this is generally good enough.

like image 140
lynkfox Avatar answered Sep 28 '22 00:09

lynkfox