-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
[lambda] Starting in 1.68.0 lambda Function.addPermission() incorrectly tries to add permission resource to remote functions #11278
Comments
Thinking more about this. The assumption made by the recent change is that if either the |
Hey @peterb154 - this is indeed a problem and your assessment is correct. This is a duplicate of #11141 |
|
…her account Originally, when a function was imported into an account agnostic stack, it was assumed that the function was from a different account and hence its permission cannot be modified. A subsequent change - 99111f7 - changed this behaviour to its opposite. When an account agnostic stack was encountered in the context of an imported function, it was assumed that the function was part of the same account. This has caused customers to report regressions - #11278, #11141. This change reverts this behaviour back to its original assumption, with the additional ability to configure this explicitly by the user if needed for an advanced use case. fixes #11141
…her account Originally, when a function was imported into an account agnostic stack, it was assumed that the function was from a different account and hence its permission cannot be modified. A subsequent change - 99111f7 - changed this behaviour to its opposite. When an account agnostic stack was encountered in the context of an imported function, it was assumed that the function was part of the same account. This has caused customers to report regressions - #11278, #11141. This change reverts this behaviour back to its original assumption, with the additional ability to configure this explicitly by the user if needed for an advanced use case. fixes #11141
…her account (#11369) Originally, when a function was imported into an account agnostic stack, it was assumed that the function was from a different account and hence its permission cannot be modified. A subsequent change - 99111f7 - changed this behaviour to its opposite. When an account agnostic stack was encountered in the context of an imported function, it was assumed that the function was part of the same account. This has caused customers to report regressions - #11278, #11141. This change reverts this behaviour back to its original assumption, with the additional ability to configure this explicitly by the user if needed for an advanced use case. fixes #11141 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Starting in 1.68.0 lambda functions imported from remote accounts can incorrectly addPermission()
The Question
This change #10622 created a situation where cdk tries to addPermission to a lambda imported from a remote account.
Environment
cdk version 1.68.0+
Example app.py
Example requirements.txt
Demonstration of the problem
v1.67.0 and prior returns the expected number (0) of AWS::Lambda::Permissions resources
But upgrade to 1.68.0 (or higher)
Returns 4 AWS::Lambda::Permissions resources. (should have none)
Source
configRule runs addPermission() on the ILambda here
https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-config/lib/rule.ts#L356-L358
and Function.addPermission changed with this change https://github.com/aws/aws-cdk/pull/10622/files which was included in 1.68.0.
I believe this change is what caused the problem.
The text was updated successfully, but these errors were encountered: