feat(stepfunctions-tasks): add awsSdkCredentials to CallAwsServiceCrossRegion for cross-account scenarios

[t3yamoto]

Issue # (if applicable)

Closes #35317.

Reason for this change

When using CallAwsServiceCrossRegion with the credentials property for cross-account scenarios, the StateMachine execution role assumes the specified credentials role and attempts to execute the auto-generated
Lambda function with that role. This causes Lambda execution failures because the cross-account role lacks lambda:InvokeFunction permissions for the Lambda function in the original account.

Description of changes

Added a new awsSdkCredentials property to CallAwsServiceCrossRegion that allows specifying IAM credentials exclusively for AWS SDK calls within the Lambda function, without affecting Lambda execution itself.

Key changes:

• Added awsSdkCredentials property to CallAwsServiceCrossRegionOptions interface
• Modified Lambda handler to accept assumeRoleArn parameter and use STS AssumeRole for AWS SDK client initialization
• Added automatic sts:AssumeRole IAM permission when awsSdkCredentials is specified
• Lambda function continues to execute with its normal execution role while AWS SDK calls use the assumed role

Design decisions:

• Chose non-breaking approach (Option 2 from issue discussion) by adding new property instead of modifying existing credentials behavior
• Used STS AssumeRole within Lambda handler rather than at Step Functions level to maintain proper separation of concerns
• Added dependency on @aws-sdk/client-sts for assume role functionality

Describe any new or updated permissions being added

When awsSdkCredentials is specified, the Lambda execution role automatically receives:

• sts:AssumeRole permission on all resources (*) to assume the specified cross-account role

Description of how you validated changes

• Added comprehensive integration test (integ.call-aws-service-cross-region-cross-account.ts) that validates cross-account and cross-region DynamoDB API calls
• Added unit tests for the Lambda handler's assume role functionality
• Integration test creates resources in two different accounts and regions to simulate real-world cross-account scenarios

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[TheRealAmazonKendra]

Thank you for your contributions! I'm not sure this is the right solution here. Adding this field makes this a leaky abstraction. The end user shouldn't have to know or care that a lambda is being used under the hood. I think that the solution here needs to be purely under the hood.

Please correct me if my understanding of this issue isn't quite correct but it seems that the state machine shouldn't have access to the credentials at all (except to pass them on) and that we're giving it permissions it should not have. That's concerning aside from the problem that the construct simply isn't working for your use case.

Fixing this may be a breaking change but I do think we need to correct where the credentials are going so we're not giving unintended permissions.

[TheRealAmazonKendra]

Can you please remove the fake account numbers here? I know it's obvious to any human reading this that these are dummy values but having a fallback fake account can sometimes cause issues both with security scanning and with running tests when running the whole suite (and therefore not actually reading the code)

[t3yamoto]

@TheRealAmazonKendra Thank you for the review and feedback!

I implemented the current approach with the awsSdkCredentials property to avoid breaking changes, but you make a valid point that modifying the behavior of the existing credentials property might be the more appropriate solution.

Regarding "users shouldn't need to know that Lambda is used under the hood" - I agree with this principle in general. However, in cases where users need to minimize trust policies, they might need to understand the internal architecture to properly configure cross-account role trust relationships. The Lambda execution role would need to be trusted by the cross-account role for the assume role operation to succeed.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing

To prevent automatic closure:

• Resume work on the PR
• OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request: "
• OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request: "

This PR will automatically close in 14 days if no action is taken.

Pull request has been modified.