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]

Thank you for the feedback!

I followed the existing pattern from other cross-account integration tests, such as integ.cross-account-pipeline-cfn-action.ts, which also uses fallback dummy account IDs ('123456789012' and '234567890123').

Are you suggesting that all existing cross-account integration tests should also remove
their fallback dummy account IDs? I found several tests following this same pattern
throughout the codebase.

Additionally, specifying fallback account IDs in the test code helps maintain consistency
of account IDs included in snapshots, avoiding snapshot diffs when different developers run
the tests with different account configurations.

Should I align with the existing pattern, or would you prefer to establish a new standard
across all cross-account integration tests?

[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.

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ☑️	Skipped	Failed ❌️
Security Guardian Results	72 ran	69 passed		3 failed

Test	Result
Security Guardian Results
packages/@aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/lambda/integ.call-aws-service-cross-region-cross-account.js.snapshot/ApiCalleeStack.template.json
codepipeline-cross-account-role-trust-scope.guard	❌ failure
guardhooks-no-root-principals-except-kms-secrets.guard	❌ failure
iam-role-no-broad-principals.guard	❌ failure

• View Security Guardian Results

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ☑️	Skipped	Failed ❌️
Security Guardian Results with resolved templates	72 ran	69 passed		3 failed

Test	Result
Security Guardian Results with resolved templates
packages/@aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/lambda/integ.call-aws-service-cross-region-cross-account.js.snapshot/ApiCalleeStack.template.json
codepipeline-cross-account-role-trust-scope.guard	❌ failure
guardhooks-no-root-principals-except-kms-secrets.guard	❌ failure
iam-role-no-broad-principals.guard	❌ failure

• View Security Guardian Results with resolved templates