-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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): Function.grant_invoke should not grant for all versions #20177
(lambda): Function.grant_invoke should not grant for all versions #20177
Comments
@kaizencc I'm confused. The new lambda behavior your are describing seems like exactly what CDK should do be default. Namely, In short, CDK is kind of contradicting the entire point of the Lambda team's change here. If a user actually does intend to grant access to all versions/aliases, they should be forced to say so explicitly. It should not happen as part of |
Hi @rittneje! It boils down to not wanting to break our customers. Without change, customer lambda invocations would fail when the customer invokes the lambda with unqualified ARN and a Qualifier request parameter. We can't let this happen, so we have to change the policy to The clear direction we're taking here is that if you want to grant less permissible policies, grant them on the version or alias you've created, not the function itself. So, our suggestion for your use case is to create an alias on the latest version and then grant invoke permissions on the alias (instead of the function). You shouldn't have to write a manual policy for that. |
@kaizencc Until this CDK change, I could use Furthermore, your suggestion to grant against the specific version/alias is not workable. If I grant access specifically to the $LATEST version (i.e., arn:aws:lambda:<region>:<account>:function:MyFunctionName:$LATEST), then the application in question is no longer permitted to invoke the unqualified ARN. So either I am forced to also make changes to the application, or I have to manually write a policy that grants access only to the unqualified ARN instead of using What the CDK team needs to do is add an optional boolean parameter to |
Hello @rittneje, I want to add some additional info and address some of your comments individually:
This is somewhat subjective. Without any bias towards the previous behavior, calling
This is conflating the meaning of
This is a fair callout. We don't want you to have to manually rewrite this all over your CDK application. You can either use
The Lambda team actually put a lot of effort into introducing this new functionality without breaking any existing customers. They spent months on notification campaigns to inform customers and working directly with customers that were using the Qualifer parameter to invoke Lambda Functions with an IAM policy that only granted permission to the unqualified ARN. Some of these customers had used the CDK to provision the relevant IAM policies. We worked together to design this solution which would enable customers to upgrade their CDK version, re-deploy their infrastructure, and subsequently NOT experience a breaking change or a degradation in service for their customers when Lambda finally made the new authorization strategy live in all accounts. The goal of all of the aws-cdk L2 construct libraries is to provide opinionated defaults that make it easier for customers to use the AWS services, it is not necessarily to align exactly with the behavior of AWS Service APIs. Saying that the CDK is contradicting Lambda in this case, does not make much sense because Lambda does not have a concept of calling
Thanks for this explanation on why our recommended solution is not satisfactory for your use case. I propose we implement a new parameter or API to allow the old behavior.
I agree with you we can make a change to enable granting invoke access only on the unqualified ARN. But we cannot make this the default behavior. No feature flag should be necessary here, we can add a new parameter or API for this. Thanks for your patience with this one, @rittneje! I understand this is frustrating, but unfortunuately we can't revert to the previous behavior. |
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
I strongly disagree. In our experience, it is extremely uncommon (read: it never happens) for someone to actually intend to grant access to invoke all versions/aliases of a function. And it is dangerous for CDK to redefine Regardless, this issue should not be closed until CDK once again provides a mechanism to grant |
Update: Our current plan is to provide a new helper function |
We've been able to work around this with: // CDK Version 2.139.1 (build b88f959)
// Old:
// lambda_obj.grantInvoke(<iam.Role>stateMachine.role)
// New:
lambda_obj.currentVersion.grantInvoke(<iam.Role>stateMachine.role) |
|
1 similar comment
|
Describe the bug
While upgrading from 1.140.0 to 2.20.0, we noticed that the behavior of
aws_lambda.Function.grant_invoke
has changed. Previously it grantedlambda:InvokeFunction
just on the function ARN itself. Now it also grantslambda:InvokeFunction
on${arn}:*
, meaning all function versions.This change does not make sense. At best, granting this wildcard permission is pointless, because CDK doesn't publish function versions. At worst, this is actually a potential security issue, because when I grant invoke rights to a principal, I mean for them to invoke it without any version number, which means
$LATEST
. If they have permission to invoke any version, then it is possible for them to invoke an older version that is not intended to be used anymore.Expected Behavior
grant_invoke
should retain its original behavior of only granting the ability to invoke the function itself, without an explicit version. If for some reason someone wants to grant wildcard access to all versions, there can be an optional boolean parameter togrant_invoke
.Current Behavior
See above.
Reproduction Steps
Create an
aws_lambda.Function
and usegrant_invoke
to grant invoke rights to some principal. Then look at the IAM policy that is generated.Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.20.0
Framework Version
No response
Node.js Version
16.14.2
OS
Alpine 3.15
Language
Python
Language Version
3.9.12
Other information
No response
The text was updated successfully, but these errors were encountered: