fix(lambda): support Lambda's new Invoke with Qualifier authorization strategy

[madeline-k]

‼️ Lambda is changing their authorization strategy, which means that some behavior that was previously valid now results in access-denied errors.

Under the new behavior, customer lambda invocations will fail if the CDK generates a policy with an unqualified ARN as the resource, and the customer invokes lambda with the unqualified ARN and the Qualifier request parameter.

Example of an affected setup:

Statement: 
{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction",
}

API Call:
lambda.Invoke({
  FunctionName: "MyFunction",
  Qualifier: "1234",
})

This Invoke call used to succeed, but under the new authorization strategy it will fail. The required statement to make the call succeed would be (note the qualified ARN):

{
  Effect: "Allow",
  Action: "lambda:InvokeFunction",
  Resource: "arn:aws:lambda:...:function:MyFunction:1234",
}

This PR aims to align the CDK with the new authorization strategy. The PR introduces changes to the grantInvoke() api on a lambda function. Now, when calling grantInvoke() on a lambda function, [ARN, ARN:*] is used in the identity policy, so that identities that are granted permission to invoke the Function may also invoke all of its Versions and Aliases.

When calling grantInvoke() on a lambda function Version or Alias, the generated identity policy will remain the same, and only include ARN:<version/alias> in the policy.

This is part of #19273

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[madeline-k]

Adding do not merge label until we decide whether or not to Feature Flag this change

[kaizencc]

If I'm not mistaken, when this is complete it should also close #17515.

[madeline-k]

If I'm not mistaken, when this is complete it should also close #17515.

@kaizen3031593, It will not. But I am planning to do that in another PR. This PR only adds [ARN, ARN:*] when you call grantInvoke on a "regular" Function. Not on a Version or Alias.

In a separate PR, we will add the [ARN, ARN:*] permissions for calling grantInvoke on a Version, when it is used in a stepfunction task. That part will fix #17515.

On a somewhat related note - calling grantInvoke on an Alias will always remain the same, and only grant permissions to ARN:alias, because one of the purposes of an Alias is to restrict users to only have access to a specific version of the function.

[kaizencc]

I updated 1. API ref, but for 2 & 3 I am going to need some help concocting a coherent message. I'll take a stab at 3. and update the description to my liking.

[madeline-k]

Really like your updates to the PR description 👍

Thanks for fighting with the integ tests! Let me know if I can help

[madeline-k]

Nice 👍

[kaizencc]

Finally got the build working for this one. Some of the integ tests have changed assets, at this point, I think that we should be okay with it. The build fails without these changes.

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: ebb9b53
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).