-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(integ-tests): apply correct IAM policy to waiterProvider #28424
Conversation
@@ -250,6 +250,19 @@ export class LambdaInvokeFunction extends AwsApiCall { | |||
arnFormat: ArnFormat.COLON_RESOURCE_NAME, | |||
resourceName: props.functionName, | |||
})]); | |||
|
|||
// If using `waitForAssertions`, do the same for `waiterProvider` as above. | |||
Aspects.of(this).add({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Resource-based policy for Lambda is created in the part shown in the link, but it is not created here because invoking Lambda from Lambda is possible if the appropriate Policy is granted to the execution role of the invoking Lambda.
new CfnResource(this, 'Invoke', { |
If you have any concerns, I would really appreciate it if you could let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this but -- can you document why you've used an Aspect so that others who stumble on your code will understand the decision please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @sakurai-ryo! Some really minor comments but this looks good!
@@ -250,6 +250,19 @@ export class LambdaInvokeFunction extends AwsApiCall { | |||
arnFormat: ArnFormat.COLON_RESOURCE_NAME, | |||
resourceName: props.functionName, | |||
})]); | |||
|
|||
// If using `waitForAssertions`, do the same for `waiterProvider` as above. | |||
Aspects.of(this).add({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this but -- can you document why you've used an Aspect so that others who stumble on your code will understand the decision please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets document here that what we are trying to verify is that Lambda.InvokeFunction
exists in the integ assertions stack, not in the actual stack that is getting "tested"
Pull request has been modified.
@kaizencc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, thanks @sakurai-ryo
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
### Description The following issue describes a bug where the IAM Policy is not correctly set to the calling Lambda when using `invokeFunction` and `waitForAssertions`. Normally, when the `waitForAssertions` method is invoked, the necessary Policy is granted to the `waiterProvider` using the `adPolicyStatementFromSdkCall` method. https://github.com/aws/aws-cdk/blob/52a5579aa52c88bb289a7a9677c35385763c8fff/packages/%40aws-cdk/integ-tests-alpha/lib/assertions/sdk.ts#L136 In the case of a Lambda function call, the API name and the Action name of the Policy are different (invoke => invokeFunction), so the `addPolicyStatementFromSdkCall` method cannot grant the correct Policy. The `LambdaInvokeFunction` is doing the correct Policy assignment to deal with this in the constructor. https://github.com/aws/aws-cdk/blob/52a5579aa52c88bb289a7a9677c35385763c8fff/packages/%40aws-cdk/integ-tests-alpha/lib/assertions/sdk.ts#L247 However, this is not done for the `waiterProvider`, resulting in an access denied error. This PR has been modified so that the correct Policy is granted to `waiterProvider`. fixes aws#27865 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Description
The following issue describes a bug where the IAM Policy is not correctly set to the calling Lambda when using
invokeFunction
andwaitForAssertions
.Normally, when the
waitForAssertions
method is invoked, the necessary Policy is granted to thewaiterProvider
using theadPolicyStatementFromSdkCall
method.aws-cdk/packages/@aws-cdk/integ-tests-alpha/lib/assertions/sdk.ts
Line 136 in 52a5579
In the case of a Lambda function call, the API name and the Action name of the Policy are different (invoke => invokeFunction), so the
addPolicyStatementFromSdkCall
method cannot grant the correct Policy.The
LambdaInvokeFunction
is doing the correct Policy assignment to deal with this in the constructor.aws-cdk/packages/@aws-cdk/integ-tests-alpha/lib/assertions/sdk.ts
Line 247 in 52a5579
However, this is not done for the
waiterProvider
, resulting in an access denied error.This PR has been modified so that the correct Policy is granted to
waiterProvider
.fixes #27865
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license