Step functions cross account access to DynamoDB

Viewed 583

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?

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.

Related