feat(cloudfront): function URL origin access control L2 construct#31339
feat(cloudfront): function URL origin access control L2 construct#31339mergify[bot] merged 51 commits intoaws:mainfrom
function URL origin access control L2 construct#31339Conversation
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
function URL origin access control L2 construct
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
gracelu0
left a comment
There was a problem hiding this comment.
Thanks for working on this so quickly @watany-dev! :)
| /** | ||
| * An Origin for a Lambda Function URL with OAC. | ||
| */ | ||
| export class FunctionUrlOriginWithOAC extends cloudfront.OriginBase { |
There was a problem hiding this comment.
Let's keep this class private as it's an implementation detail and not intended for public usage
| new cloudfront.Distribution(stack, 'MyDistribution', { | ||
| defaultBehavior: { | ||
| origin: FunctionUrlOrigin.withOriginAccessControl(fnUrl, { | ||
| originAccessControl: undefined, |
There was a problem hiding this comment.
why is undefined passed here? Could we just leave out the props altogether?
| this.originAccessControl = new cloudfront.FunctionUrlOriginAccessControl(scope, 'FunctionUrlOriginAccessControl'); | ||
| } | ||
|
|
||
| new lambda.CfnPermission(scope, `InvokeFromApiFor${options.originId}`, { |
There was a problem hiding this comment.
Can we move this into a private function? It would make it clearer and easier to understand why a new permission is getting created
There was a problem hiding this comment.
Also is it possible to use any existing grant or addPermission methods here instead? And how do we handle permissions for imported lambda functions?
There was a problem hiding this comment.
It seems like there might still be a potential bug with addPermission, so I’m using cfnPermission instead. It’s not too complex, and since the cross-stack test is passing, I don't have any concerns. Here’s a reference (apologies, it's in Japanese!) https://dev.classmethod.jp/articles/cdk-over-21-lambda-create-error/.
...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts
Show resolved
Hide resolved
|
|
||
| const template = Template.fromStack(stack); | ||
|
|
||
| template.hasResourceProperties('AWS::CloudFront::Distribution', { |
There was a problem hiding this comment.
since this test is checking for the correct permissions, can we also check the AWS::Lambda::Permission resource exists in the template and has the expected policy?
packages/aws-cdk-lib/aws-cloudfront-origins/lib/function-url-origin.ts
Outdated
Show resolved
Hide resolved
|
Just to confirm, will this proposal work well with Lambda function aliases and versions? Background: Lambda provisioned concurrency only works with Lambda function versions or aliases. Given that, we have all of our function URLs pointing to aliases instead of "normal" Lambda functions. Before this was merged, just wanted to make sure this PR would also accommodate function URLs backed by versions/aliases. From updated README looks like the answer is yes and it would be something like: Might be worth adding to README updates given this may be a pretty common pattern. |
| body: 'Forbidden', | ||
| })); | ||
|
|
||
| app.synth(); |
There was a problem hiding this comment.
nit: we no longer need app.synth() in integ tests so this line can be removed from the new integ tests
Thanks for pointing out this use case! I tested setting up a Lambda function alias with OAC with this API and it deployed/setup successfully. @watany-dev could you please add an integration test and README example for this use case? |
|
@rhermes62 @gracelu0 |
|
Thank you @watany-dev ! We are still pending the security review and service team confirmation, we appreciate your effort and patience in getting this reviewed. |
packages/aws-cdk-lib/aws-cloudfront-origins/lib/function-url-origin.ts
Outdated
Show resolved
Hide resolved
Pull request has been modified.
|
@gracelu0 |
|
Hi @watany-dev , I think it looks good! Just waiting on confirmation from security reviewer before I approve (should be very soon!). |
gracelu0
left a comment
There was a problem hiding this comment.
Thank you so much for working on this @watany-dev !
|
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). |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #31339 +/- ##
=======================================
Coverage 77.18% 77.18%
=======================================
Files 105 105
Lines 7161 7161
Branches 1312 1312
=======================================
Hits 5527 5527
Misses 1454 1454
Partials 180 180
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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). |
|
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
#31629
Reason for this change
This change introduces support for Lambda Function URLs with custom Origin Access Control (OAC) in CloudFront distributions, enhancing security and control over CloudFront-Lambda integration.
Description of changes
Description of how you validated changes
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license