Skip to content
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

CloudFrontToS3: Stack fails deployment after cdk-lib version update #1206

Open
tbelmega opened this issue Sep 19, 2024 · 1 comment
Open
Labels
addressed Issue is addressed either through a release or further explanation Backlog We don't have the bandwidth to support this task right now, but will consider it in the future.

Comments

@tbelmega
Copy link
Contributor

tbelmega commented Sep 19, 2024

I updated my aws-cdk library version and aws-solutions-constructs version to the latest (v2.158.0/v2.70).
After the update, my stack failed to deploy. CloudFormation responds with

“Invalid request provided: AWS::CloudFront::Distribution: Cannot use both Origin Access Control and Origin Access Identity on an origin (Service: CloudFront, Status Code: 400, Request ID: xxx)” (RequestToken: yyy, HandlerErrorCode: InvalidRequest)

Reproduction Steps

Reference in solution code

    new CloudFrontToS3(scope, 'CloudFront',
      {
        existingBucketObj: bucket,
        insertHttpSecurityHeaders: false,
        cloudFrontDistributionProps: {
          defaultBehavior: {
            origin: new S3Origin(this.s3BucketInterface),
          }
        } as DistributionProps
      }
    );

This code worked with aws-cdk-lib prior to 2.148.0, and throws an error at deployment time since I upgraded to 2.158.0.

The fix for my solution is to change
origin: new S3Origin(this.s3BucketInterface),
to
origin: S3BucketOrigin.withOriginAccessControl(this.s3BucketInterface),

Error Log

Invalid request provided: AWS::CloudFront::Distribution: Cannot use both Origin Access Control and Origin Access Identity on an origin (Service: CloudFront, Status Code: 400, Request ID: xxx)" (RequestToken: yyy, HandlerErrorCode: InvalidRequest)

Environment

  • CDK CLI Version : 2.158.0
  • CDK Framework Version:2.158.0
  • AWS Solutions Constructs Version :2.70.0
  • OS :MacOS
  • Language :Typescript

Other


This is 🐛 Bug Report

@tbelmega tbelmega added bug Something isn't working needs-triage The issue or PR still needs to be triaged labels Sep 19, 2024
@biffgaut
Copy link
Contributor

Here's what's going on - up through version 2.47.0 the aws-cloudfront-s3 would create and deploy an OAI between the distribution and the origin. When a client created an S3Origin and sent it through the cloudFrontDistributionProps, it would overwrite the S3Origin in the props sent to the Distribution constructor. Since an S3Origin was an object but not a construct, there were no negative repercussions from both the client and Solutions Construct creating one.

When the OAC was introduced, it became the recommended technology and regions launched after December 2022 will not support OAI. The S3Origin class has been deprecated (did you catch me using "was" earlier?), and apps should be moving to OAC. With version 2.48.0, the aws-cloudfront-s3 construct switched to an OAC implementation. Clients that relied on the construct to create the origin were able migrate to OAC with little to no effort. The construct now sends an OAC to the Distribution constructor. Any S3Origin received from the client, such as in the code above, no longer overwrites the S3Origin created by the construct - it gets sent to the Distribution constructor alongside the OAC, and the result is the error above.

A simple solution is just to allow the consttruct to create the OAC:

    new CloudFrontToS3(scope, 'CloudFront',
      {
        existingBucketObj: bucket,
        insertHttpSecurityHeaders: false,
        cloudFrontDistributionProps: {
        } as DistributionProps
      }
    );

You can still set things like viewerProtocolPolicy or responseHeadersPolicy through the defaultBehavior in the Distribution props (although we'd recommend using CloudFrontToS3Props.responseHeadersPolicyProps and letting the Solutions Construct do the work).

We could perceive a use case where a client wanted very specialized behavior in the OAC, and needed to set specific OriginProps, although that doesn't seem to be an issue in the example above (which may be simplified). If customers have a need to set specific OriginProps, they can register that need here or in a new Issue and we can look at prioritizing it.

@biffgaut biffgaut added Backlog We don't have the bandwidth to support this task right now, but will consider it in the future. addressed Issue is addressed either through a release or further explanation and removed bug Something isn't working needs-triage The issue or PR still needs to be triaged labels Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed Issue is addressed either through a release or further explanation Backlog We don't have the bandwidth to support this task right now, but will consider it in the future.
Projects
None yet
Development

No branches or pull requests

2 participants