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

watany-dev · 2024-09-06T09:45:27Z

Issue # (if applicable)

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

My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES
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

aws-cdk-automation

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.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

…b.com/watany-dev/aws-cdk into lambda-url-oac

gracelu0

Thanks for working on this so quickly @watany-dev! :)

gracelu0 · 2024-09-10T01:54:11Z

packages/aws-cdk-lib/aws-cloudfront-origins/lib/function-url-origin.ts

+ * An Origin for a Lambda Function URL with OAC.
+ */
+export class FunctionUrlOriginWithOAC extends cloudfront.OriginBase {


Let's keep this class private as it's an implementation detail and not intended for public usage

fixed.
a43bf40

gracelu0 · 2024-09-10T02:10:39Z

packages/aws-cdk-lib/aws-cloudfront/test/origin-access-control.test.ts

@@ -59,4 +59,56 @@ describe('S3OriginAccessControl', () => {

    expect(imported.originAccessControlId).toEqual(originAccessControlId);
  });
+
+  test('creates a FunctionUrlOriginAccessControl with default properties', () => {


Can we nest the new tests under a new describe, e.g.

describe('FunctionUrlOriginAccessControl', () => { test(...); });

fixed.
3731370

gracelu0 · 2024-09-10T02:21:06Z

packages/aws-cdk-lib/aws-cloudfront-origins/test/function-url-origin.test.ts

+  new cloudfront.Distribution(stack, 'MyDistribution', {
+    defaultBehavior: {
+      origin: FunctionUrlOrigin.withOriginAccessControl(fnUrl, {
+        originAccessControl: undefined,


why is undefined passed here? Could we just leave out the props altogether?

fixed.
f660a83

gracelu0 · 2024-09-10T02:39:43Z

packages/aws-cdk-lib/aws-cloudfront-origins/lib/function-url-origin.ts

+    }
+
+    new lambda.CfnPermission(scope, `InvokeFromApiFor${options.originId}`, {


Can we move this into a private function? It would make it clearer and easier to understand why a new permission is getting created

Also is it possible to use any existing grant or addPermission methods here instead? And how do we handle permissions for imported lambda functions?

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

fixed.
2ad9170
989141b

gracelu0 · 2024-09-10T02:45:09Z

...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts

+  },
+});
+
+// Set up integration test


Can we add an assertion to this test that calls the cloudfront distribution endpoint and checks the response is as expected?

Thanks for adding those assertions! What I was thinking of originally was using the httpApiCall method to the distribution domain and verifying the response from the lambda (something like this test)

const resp = JSON.stringify({ statusCode: 200, body: 'Hello!!' }); const fn = new lambda.Function(this, 'MyLambda', { runtime: lambda.Runtime.NODEJS_20_X, code: lambda.Code.fromInline(`exports.handler = async (event) => {return ${resp}}`), handler: 'index.handler' }); ... const call = integ.assertions.httpApiCall(`https://${distribution.distributionDomainName}`); call.expect(ExpectedResult.objectLike({ status: 200, body: 'Hello!!', }));

Let me know if that wouldn't work for some reason.

@gracelu0

Your comment passed the test correctly. This will ensure its appropriateness.

gracelu0 · 2024-09-10T02:50:34Z

packages/aws-cdk-lib/aws-cloudfront-origins/test/function-url-origin.test.ts

+
+  const template = Template.fromStack(stack);
+
+  template.hasResourceProperties('AWS::CloudFront::Distribution', {


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?

fixed.
7226680

watany-dev · 2024-09-26T16:47:39Z

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

godwingrs22 · 2024-09-26T16:53:21Z

...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts

+
+// Add a Lambda Function URL
+const fnUrl = fn.addFunctionUrl({
+  authType: lambda.FunctionUrlAuthType.AWS_IAM,


Just for my understanding, I would like to understand the behaviour of AuthType in Function URL with Cloudfront-Lambda integration with OAC origin.

May i know if authType = AWS_IAM is the only supported authType in lamda function URL for Cloudfront OAC Lambda Function url origin?

Or Is authType = None supported for OAC? If it is not supported, Let us mention it in ReadMe and also update the current example.

If both are supported, I would recommend to have unit test for both types.

OAC can communicate when authType = none and the necessary permissions are granted. When None is set in the L2 construct, the latter permission is automatically configured, so there are no issues. Therefore, I have prepared a test for the None case.

I did some deep dive on these two types and noticed the following behaviour.

When authType = AWS_IAM, then Lambda expects the request is signed. If the request is not signed then it throws error.

When authType = None, then Lambda function is configured for public access and can be accessed without any IAM credential.

Hence for OAC, I believe the current logic will allow the following scenario which shouldn't be allowed.

If authType = None and OAC Signing is SIGV4_ALWAYS, then direct lambda call(without iam sigv4 credentials) is still being allowed and sigv4 credentials generated by cloudfront OAC in the request which is passed to lambda is not validated at lambda side as the authType is None. I believe this defeats the purpose of having OAC. The expectation will be if OAC is configured with SIGV4_ALWAYS, then we expect lambda is not publicly accessible directly and will be accessible only through cloudfront endpoint which internally performs sigv4 signing.

I recommend we throw synth exception if authType = None and OAC Signing is SIGV4_ALWAYS is used. Based on this AWS post, seems the recommended configuration is authType = AWS_IAM and OAC signing as SIGV4_ALWAYS.

Eg:

OAC Signing behaviour `SIGV4_ALWAYS` requires Lambda Function URL AuthType to be set to AWS_IAM

I would suggest you to validate the above scenario and also have separate unit test for each behaviour. Please correct me if my understanding is wrong.

Reference :
https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html

https://aws.amazon.com/blogs/networking-and-content-delivery/secure-your-lambda-function-urls-using-amazon-cloudfront-origin-access-control/

godwingrs22 · 2024-09-26T18:04:54Z

...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts

+// Create CloudFront Distribution with OAC
+const distribution = new cloudfront.Distribution(stack, 'Distribution', {
+  defaultBehavior: {
+    origin: origins.FunctionUrlOrigin.withOriginAccessControl(fnUrl),


Also I would recommend to have a another integ test for the custom OAC with new L2 construct FunctionUrlOriginAccessControl and using it in withOriginAccessControl method

godwingrs22 · 2024-09-26T18:27:12Z

packages/aws-cdk-lib/aws-cloudfront-origins/lib/function-url-origin.ts

+    super(domainName, props);
+    this.functionUrl = lambdaFunctionUrl;
+    this.props = props;


I believe we need this.originAccessControl = this.props?.originAccessControl still to set the custom OAC.

This is because originAccessControlId is being used in the bind method from this.originAccessControl. Hence for scenario where custom OAC is passed, I suspect it wont be able to retrieve the originAccessControlId based on the current logic. Please correct me if my understanding is incorrect.

You are right. I fixed it.

godwingrs22

Thanks @watany-dev for addressing the feedback. I left few more comments. Also, Please be informed that this PR requires security review and I'm checking internally on the same. I'll let you know once it is security approved.

godwingrs22 · 2024-09-27T14:27:09Z

...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts

+  body: 'Hello!!',
+}));
+
+const customOacStack = new cdk.Stack(app, 'integ-cloudfront-function-url-origin-custom-oac');


I would recommend to have this integ test as a separate file so that the snapshot for this test will be generated separately.

fixed
fea5a32

godwingrs22 · 2024-09-27T14:40:36Z

...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts

+// Make an HTTP call to the CloudFront distribution and verify the response
+const customOacHttpCall = customOacInteg.assertions.httpApiCall(`https://${customOacDistribution.distributionDomainName}`);
+customOacHttpCall.expect(ExpectedResult.objectLike({
+  status: 200,
+  body: 'Hello!!',
+}));
+


Can we put another api call assertion below this to directly call lambda function url and make sure we are not able to get the expected response and getting HTTP 403 response code from lambda. Our expectation is we won't be able to call the lambda function url directly if OAC is setup and can be only accessible via cloudfront.

fixed. 873777b

godwingrs22 · 2024-09-27T15:12:35Z

packages/aws-cdk-lib/aws-cloudfront-origins/test/function-url-origin.test.ts

+    const oac = new cloudfront.FunctionUrlOriginAccessControl(stack, 'CustomOAC', {
+      originAccessControlName: 'CustomLambdaOAC',
+      signing: cloudfront.Signing.SIGV4_ALWAYS,
+    });


Can we separate this test case into two to validate below scenarios?

Custom OAC without signing prop defined

This will create OAC with default signing which is SIGV4_ALWAYS

const oac = new cloudfront.FunctionUrlOriginAccessControl(stack, 'CustomOAC', { originAccessControlName: 'CustomLambdaOAC', });

Custom OAC with signing prop defined

This will create OAC with signing defined. Let us use SIGV4_NO_OVERRIDE to assert

const oac = new cloudfront.FunctionUrlOriginAccessControl(stack, 'CustomOAC', { originAccessControlName: 'CustomLambdaOAC', signing: cloudfront.Signing.SIGV4_NO_OVERRIDE, });

fixed, fd9f9b4

godwingrs22 · 2024-09-27T16:49:55Z

...dk-testing/framework-integ/test/aws-cloudfront-origins/test/integ.function-url-origin-oac.ts

+
+// Add a Lambda Function URL
+const fnUrl = fn.addFunctionUrl({
+  authType: lambda.FunctionUrlAuthType.AWS_IAM,


I did some deep dive on these two types and noticed the following behaviour.

When authType = AWS_IAM, then Lambda expects the request is signed. If the request is not signed then it throws error.

When authType = None, then Lambda function is configured for public access and can be accessed without any IAM credential.

Hence for OAC, I believe the current logic will allow the following scenario which shouldn't be allowed.

If authType = None and OAC Signing is SIGV4_ALWAYS, then direct lambda call(without iam sigv4 credentials) is still being allowed and sigv4 credentials generated by cloudfront OAC in the request which is passed to lambda is not validated at lambda side as the authType is None. I believe this defeats the purpose of having OAC. The expectation will be if OAC is configured with SIGV4_ALWAYS, then we expect lambda is not publicly accessible directly and will be accessible only through cloudfront endpoint which internally performs sigv4 signing.

I recommend we throw synth exception if authType = None and OAC Signing is SIGV4_ALWAYS is used. Based on this AWS post, seems the recommended configuration is authType = AWS_IAM and OAC signing as SIGV4_ALWAYS.

Eg:

OAC Signing behaviour `SIGV4_ALWAYS` requires Lambda Function URL AuthType to be set to AWS_IAM

I would suggest you to validate the above scenario and also have separate unit test for each behaviour. Please correct me if my understanding is wrong.

Reference :
https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html

https://aws.amazon.com/blogs/networking-and-content-delivery/secure-your-lambda-function-urls-using-amazon-cloudfront-origin-access-control/

watany-dev · 2024-09-28T02:48:06Z

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

Pull request has been modified.

godwingrs22 · 2024-10-01T14:19:01Z

packages/aws-cdk-lib/aws-cloudfront-origins/test/function-url-origin.test.ts

+      },
+    });
+  });
+  test('Creates Lambda Function URL origin with default OAC and origin properties', () => {


nit: seems this test is duplicated. It is similar to test Correctly creates a Lambda Function URL Origin with default properties

godwingrs22 · 2024-10-01T15:23:27Z

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 · 2024-10-01T16:43:34Z

@godwingrs22
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?
fcf8db0

godwingrs22 · 2024-10-01T20:00:14Z

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.

…31590) ### Reason for this change I will resolve this issue: #31339 (comment). In the current FunctionURL implementation, there is no way to access AuthType, and therefore, when writing logic that depends on AuthType, there is no method to reference it. ### Description of changes I will fix the construct to allow access to functionurl.AuthType ### Description of how you validated changes adding unittest and integ-test re-run. ### Reason for Exemption: The fix introduces no changes to the resources being created. ### Clarification Request: This fix only makes the internal property authType of the L2 Construct publicly accessible, and does not introduce any differences in the created resources. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

aws-cdk-automation · 2024-10-13T09:20:22Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
Commit ID: fce4e73
Result: FAILED
Build Logs (available for 30 days)

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

watany-dev added 2 commits September 6, 2024 07:07

oac

bc5f929

wip: oac fin

80f07f7

github-actions bot added p2 distinguished-contributor [Pilot] contributed 50+ PRs to the CDK labels Sep 6, 2024

aws-cdk-automation requested a review from a team September 6, 2024 09:45

aws-cdk-automation previously requested changes Sep 6, 2024

View reviewed changes

watany-dev added 4 commits September 6, 2024 16:16

oai

a6386c1

fix oai

da605ea

remove oai

b2baafa

snapshoted

5a7352a

watany-dev changed the title ~~WIP: feat(cloudfront): Function URL origin access control L2 construct~~ feat(cloudfront): Function URL origin access control L2 construct Sep 7, 2024

Merge branch 'main' into lambda-url-oac

8e8e2ac

watany-dev changed the title ~~feat(cloudfront): Function URL origin access control L2 construct~~ feat(cloudfront): function URL origin access control L2 construct Sep 7, 2024

watany-dev added 3 commits September 7, 2024 08:38

fix doctest

7fcbea3

Merge branches 'lambda-url-oac' and 'lambda-url-oac' of https://githu…

12f13f9

…b.com/watany-dev/aws-cdk into lambda-url-oac

snapshotted

b257227

watany-dev mentioned this pull request Sep 7, 2024

Support AWS SigV4 signatures for Lambdalith's running Hono with IAM Authorization - RPC Client-side honojs/hono#3382

Open

watany-dev added 3 commits September 7, 2024 14:06

fix doctest

8f24a4a

fixed

81c0785

refactor

47775c8

aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 8, 2024

Merge branch 'main' into lambda-url-oac

df0c972

moelasmar requested a review from gracelu0 September 8, 2024 06:55

github-actions bot mentioned this pull request Sep 9, 2024

Weekly PR metrics report #31370

Open

gracelu0 previously requested changes Sep 10, 2024

View reviewed changes

aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 10, 2024

watany-dev added 3 commits September 10, 2024 16:58

hide private class

a43bf40

nest the new tests under a new describe

3731370

just leave out the props altogether

f660a83

Merge branch 'main' into lambda-url-oac

693abfe

watany-dev requested a review from godwingrs22 September 26, 2024 16:44

godwingrs22 reviewed Sep 26, 2024

View reviewed changes

watany-dev added 3 commits September 27, 2024 07:19

revert this.oac

92f7e71

integ

adc12d3

Authtype.None

e4817ff

watany-dev requested a review from godwingrs22 September 27, 2024 08:59

godwingrs22 previously requested changes Sep 27, 2024

View reviewed changes

aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 27, 2024

watany-dev added 3 commits September 28, 2024 03:00

Split OAC Configuration Test for Default and Custom Signing Behavior

fd9f9b4

split integ

fea5a32

update integ

873777b

aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 28, 2024

watany-dev mentioned this pull request Sep 28, 2024

chore(lambda): resolve unable to reference AuthType from FunctionUrl #31590

Merged

1 task

godwingrs22 reviewed Oct 1, 2024

View reviewed changes

watany-dev added 2 commits October 1, 2024 16:32

update doc

fcf8db0

remove duplicate test

2375bcd

watany-dev requested a review from godwingrs22 October 1, 2024 16:44

watany-dev added 2 commits October 5, 2024 22:25

Merge branch 'aws:main' into lambda-url-oac

a6f5726

adding warning

fce4e73

		}

		new lambda.CfnPermission(scope, `InvokeFromApiFor${options.originId}`, {


		const template = Template.fromStack(stack);

		template.hasResourceProperties('AWS::CloudFront::Distribution', {

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

Are you sure you want to change the base?

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

Conversation

watany-dev commented Sep 6, 2024 • edited by gracelu0 Loading

Reason for this change

Description of changes

Description of how you validated changes

Checklist

aws-cdk-automation left a comment

Choose a reason for hiding this comment

gracelu0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

watany-dev Sep 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

watany-dev commented Sep 26, 2024

godwingrs22 Sep 26, 2024 • edited Loading

Choose a reason for hiding this comment

watany-dev Sep 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

godwingrs22 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

watany-dev Sep 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

watany-dev commented Sep 28, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

godwingrs22 commented Oct 1, 2024

watany-dev commented Oct 1, 2024

godwingrs22 commented Oct 1, 2024

aws-cdk-automation commented Oct 13, 2024

AWS CodeBuild CI Report

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

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

watany-dev commented Sep 6, 2024 •

edited by gracelu0

Loading

watany-dev Sep 10, 2024 •

edited

Loading

godwingrs22 Sep 26, 2024 •

edited

Loading

watany-dev Sep 27, 2024 •

edited

Loading

watany-dev Sep 28, 2024 •

edited

Loading