feat(cloudfront): `function URL` origin access control L2 construct

[watany-dev]

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

• Added a new feature allowing the configuration of Lambda Function URLs with custom OAC in CloudFront.
• Implemented support for custom signing behavior and protocols for Lambda origins.
• Included new tests to validate the correct behavior of OAC with Lambda Function URLs.

Description of how you validated changes

• Ran unit tests to ensure that the OAC setup for Lambda Function URLs is correctly applied in CloudFront distributions.
• Validated by deploying a sample CDK application to confirm the functionality and integration of Lambda Function URLs with CloudFront using OAC.

Checklist

• [x] My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES
• [x] OAC implementation is complete.

---

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

[watany-dev]

note: There are still remaining fixes needed for the integration tests.

[watany-dev]

@gracelu0 Thank you for the swift review. All tasks, including the integration test, have been completed. Could you please verify?

[watany-dev]

@gracelu0

Sorry for rushing you when you're busy, but could I ask you to review this?

[watany-dev]

@godwingrs22 Thanks for the review. Those are pertinent comments and have been corrected.

[watany-dev]

@godwingrs22

I understand the content, but this cannot be achieved with the current implementation.

The lambda.FunctionUrl property does not include authType, which means, for example, the URL Auth Type of an imported function cannot be identified within the Origin construct.

May I request permission to add this property as a prerequisite patch? Once this property is added, we can merge it into the main branch, either in this commit or a separate one, to resolve this issue.

[godwingrs22]

The lambda.FunctionUrl property does not include authType, which means, for example, the URL Auth Type of an imported function cannot be identified within the Origin construct.

I see. Thanks for checking.

May I request permission to add this property as a prerequisite patch? Once this property is added, we can merge it into the main branch, either in this commit or a separate one, to resolve this issue.

Sorry, I didn't get it. Could you please elaborate your suggestion?

I think we can also update the readMe to specify to use the recommended value for Lambda Function url AuthType as AWS_IAM if OAC Signing SIGV4_ALWAYS is used. Also update the authtype given in the readMe example to AWS_IAM instead of None.

[watany-dev]

@godwingrs22 I assumed that I was being asked for a validation feature, so I submitted a pull request at https://github.com/aws/aws-cdk/pull/31590. However, if this is unnecessary at this point and can be resolved by updating the Readme first, how does this draft look? https://github.com/aws/aws-cdk/pull/31339/commits/fcf8db0727025ff89ca22e33ee33511f999dcef8

[godwingrs22]

Thank you @watany-dev for addressing the feedback promptly and appreciate your great effort.

I assumed that I was being asked for a validation feature, so I submitted a pull request at #31590. However, if this is unnecessary at this point and can be resolved by updating the Readme first, how does this draft look?

Let us keep the current readme with recommendation(which you have already updated) and also have this validation feature as well for the recommended AWS best practises. Hence, let's get the other PR #31590 merged first and then we can add this validation later in this PR. Regarding the validation, let's throw synth warning instead of exception to use the recommended value for function url authType = AWS_IAM if OAC signing is SIGV4_ALWAYS

Aside, I'm also following up internally for the security review and will let you know incase if there is any changes needs to be made from security prespective.

[rhermes62]

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:

const alias = fn.addAlias('Live', { provisionedConcurrentExecutions });

const aliasUrl = alias.addFunctionUrl({
  authType: lambda.FunctionUrlAuthType.AWS_IAM,
});

new cloudfront.Distribution(this, 'MyDistribution', {
  defaultBehavior: {
    origin: origins.FunctionUrlOrigin.withOriginAccessControl(aliasUrl),
  },
});

Might be worth adding to README updates given this may be a pretty common pattern.

[gracelu0]

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:

const alias = fn.addAlias('Live', { provisionedConcurrentExecutions });

const aliasUrl = alias.addFunctionUrl({
  authType: lambda.FunctionUrlAuthType.AWS_IAM,
});

new cloudfront.Distribution(this, 'MyDistribution', {
  defaultBehavior: {
    origin: origins.FunctionUrlOrigin.withOriginAccessControl(aliasUrl),
  },
});

Might be worth adding to README updates given this may be a pretty common pattern.

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?

[watany-dev]

@rhermes62 @gracelu0 Thank you. I am happy to share that I was also able to confirm the Alias pattern. https://github.com/aws/aws-cdk/pull/31339/commits/8be1369ce8462835cdecf0c176d467ecc13a9e2f

[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.

[watany-dev]

@gracelu0 Could you please provide an update on the status of this review?

[gracelu0]

Hi @watany-dev , I think it looks good! Just waiting on confirmation from security reviewer before I approve (should be very soon!).

[mergify[bot]]

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[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.18%. Comparing base (771eeff) to head (d838678). Report is 1 commits behind head on main.

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           

Flag	Coverage Δ
suite.unit	77.18% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
packages/aws-cdk	77.18% <ø> (ø)

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: d83867897c2ee47ee76c3bb03a84b4c84d368f1e
• Result: SUCCEEDED
• Build Logs (available for 30 days)

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

[mergify[bot]]

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).

[github-actions[bot]]

Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.