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): fromFunctionArn no longer working #18967
Comments
Related to #18781, please see #18781 (comment) for my take on what is going on. @alamathe1, a couple of questions:
|
|
Cool! Going to close this as a duplicate of #18781, since it is the same use case. There's some good information on what's happening in that thread. |
|
…ured permissions (#18979) There have been a few reports of regressions after #18228 was merged in v1.139.0: #18781, #18967. AFAIK, #18228 fixed a bug in our environment configuring logic for `fromFunctionAttributes()`, so the environment is now being properly passed to the `functionBase` that CDK creates. The bug was being relied on by CDK customers for a particular use case: calling `grantInvoke()` on imported cross-account lambdas with pre-configured permissions. In general, `grantInvoke()` modifies the trust policy of the resource if it is not from the same environment. In the case of cross-account lambdas, this is impossible, and results in a synth-time error. CDK users know this and have modified the lambda permissions in question to have the correct permissions. These users do not need permissions added to the cross-account lambda, so it is not an error. To support this use case, I'm introducing `skipPermissions` as a property for `fromFunctionAttributes()`. When set, we skip this synth-time check all together. Beware, users who set this property are now on their own for the permissions of their cross-account lambda. ```ts const fn = lambda.Function.fromFunctionAttributes(stack, 'Function', { functionArn: 'arn:aws:lambda:us-east-1:123456789012:function:MyFn', skipPermissions: true, }); ``` Closes #18781. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ured permissions (aws#18979) There have been a few reports of regressions after aws#18228 was merged in v1.139.0: aws#18781, aws#18967. AFAIK, aws#18228 fixed a bug in our environment configuring logic for `fromFunctionAttributes()`, so the environment is now being properly passed to the `functionBase` that CDK creates. The bug was being relied on by CDK customers for a particular use case: calling `grantInvoke()` on imported cross-account lambdas with pre-configured permissions. In general, `grantInvoke()` modifies the trust policy of the resource if it is not from the same environment. In the case of cross-account lambdas, this is impossible, and results in a synth-time error. CDK users know this and have modified the lambda permissions in question to have the correct permissions. These users do not need permissions added to the cross-account lambda, so it is not an error. To support this use case, I'm introducing `skipPermissions` as a property for `fromFunctionAttributes()`. When set, we skip this synth-time check all together. Beware, users who set this property are now on their own for the permissions of their cross-account lambda. ```ts const fn = lambda.Function.fromFunctionAttributes(stack, 'Function', { functionArn: 'arn:aws:lambda:us-east-1:123456789012:function:MyFn', skipPermissions: true, }); ``` Closes aws#18781. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
We are facing an error with CDK version 1.143.0 with the following usage:
The above code fails when
sameEnviroment
flag is not explicitly set totrue
. Workaround used today:NOTE: The issue is not seen on previously used CDK version 1.111.0.
Reproduction Steps
This is used by an internal amazon package. Following is an error snippet with the CDK package is complied:
What did you expect to happen?
Expected the CDK package to compile successfully without any errors.
What actually happened?
Build failed with the error:
CDK CLI Version
1.143.0
Framework Version
No response
Node.js Version
12.22.9
OS
macos
Language
Typescript
Language Version
4.1.3
Other information
No response
The text was updated successfully, but these errors were encountered: