cloudfront: Support Origin Access Control

[laurelmay]

Describe the feature

Amazon CloudFront now supports Origin Access Control, an improved method for accessing S3 Origins over Origin Access Identity.

It seems that the CloudFormation documentation (and resource specification) has not yet been updated but the OAC docs contain an example of deploying using CloudFormation.

I am opening an issue to discuss this because the S3Origin class currently only supports OAI and creates one by default; migrating to do so would likely

Use Case

The release announcement and documentation describe OAC as an improvement over OAI. OAC supports requests other than GET as well as SSE-KMS, and all AWS regions. Documentation already refers to OAI as "legacy".

Proposed Solution

I propose doing all of the following:

• Implement a feature flag, @aws-cdk/aws-cloudfront:useOriginAccessControl. When this is true, by default an OAC will be used instead of an OAI.
• Create an L2 construct for an OriginAccessControl; use an enum for SigningBehavior and SigningType. Maybe for OriginAccessControlOriginType too.
• Add an originAccessControl prop to S3OriginProps of type cloudfront.IOriginAccessControl. When truthy, this is used and an OAI is not created. When not specified, an OAI is created and used
• Have S3Origin add the necessary statements to the S3 bucket resource policy

Feature flag behavior

Flag value	S3Props.originAccessIdentity provided	S3Props.originAccessControl provided	Behavior
true	no	no	Only an OAC is created and used
true	yes	no	The given OAI is used and an OAC is created and used
true	no	yes	The given OAC is used, no OAI is created
true	yes	yes	The given OAI and given OAC are used
false	no	no	An OAI is created and used
false	yes	no	The given OAI is used, no OAC is created
false	no	yes	The given OAC is used, no OAI is created or used
false	yes	yes	The given OAI and given OAC are used

To migrate, a user would enable the feature flag. If they were already passing an OAI, they'd run with both side-by-side (a supported configuration), if not they'd use only an OAC. To migrate to OAC-only, they can then use a custom-created OAC or the default one.

Other Information

The CreateOriginAccessControl action seems like it's pretty likely to map 1:1 to the CloudFormation resource https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html. The example in the docs is:

Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      DisplayName: ExampleOAC
      OriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4

Implementation requires a new CloudFormation Resource Specification but since an example is given in the CloudFront docs, hopefully that won't take and since this may require other changes, having a conversation may be helpful.

This felt smaller than an RFC but I'm happy to open one if needed.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.39.0

Environment details (OS name and version, etc.)

[peterwoodworth]

We should have L1 support soon, any higher level abstractions for this new feature may take a bit to be implemented as we see how customers use the L1 construct

[zwlego]

Hey, Is the L1 support out? Is it for now we can only use OAI with CDK? Thanks

We should have L1 support soon, any higher level abstractions for this new feature may take a bit to be implemented as we see how customers use the L1 construct

[laurelmay]

Hey, Is the L1 support out? Is it for now we can only use OAI with CDK? Thanks

It looks like L1 updates may currently be failing due to #21957

Okay, so while it's true that updates haven't happen, the required type has not made it into the resource specification yet. So this is still basically waiting on CloudFormation Resource Specification to update.

[agdimech]

I just had a look and do actually see the OAC in the resource specification listed as:

"AWS::CloudFront::OriginAccessControl": {
      "Documentation": "http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html",
      "Properties": {
        "OriginAccessControlConfig": {
          "Documentation": "http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html#cfn-cloudfront-originaccesscontrol-originaccesscontrolconfig",
          "UpdateType": "Mutable",
          "Required": true,
          "Type": "OriginAccessControlConfig"
        }
      },
      "Attributes": {
        "Id": {
          "PrimitiveType": "String"
        }
      }
    },

[laurelmay]

Oh nice! Yeah, so it looks like now this actually is blocked by #21957 (or the underlying tracked issue) since OAC was added in spec v88.0.0!

[agdimech]

Looks like once this PR is merged and released we should have L1 constructs :)

#22026

[laurelmay]

I've started poking at implementing this (based off the branch created by #22026) and the real pain is going to be from the fact that the principal of the OAC is the CloudFront service principal with a condition of { StringEquals: { "AWS:SourceArn": "DISTRIBUTION_ARN" } }; however, the OAC does not "know" the ARN of the Distribution, so it has to be calculated. Doing so would require passing the Distribution (or a property of it) to the S3Origin construct (because the Bucket Policy will need to be modified) and today, that doesn't really happen anywhere; it'd require a deeper dive into the Origin API and a lot of the binding/resolving that happens there.

This can possibly be solved with some lazy evaluation but it will probably require a bit more than that.

A somewhat obvious (and equally obviously suboptimal) solution would be to not specify the Condition shown in the docs and to instead just allow the raw service principal but that's excessively (and likely, to most, unacceptably) broad access.

Another thing is that while the examples in the docs always show a 1:1 OAC:Origin mapping, the CloudFormation resource structure seems to imply that it could be many:many (whether the underlying service allows this is a different matter).

Even if a Distribution "silently" created an OAC, that would need to be passed to the Origin constructs (for the distribution ARN and the OAC ID). But some good news is that at least if passing this data around is solved, adding the statement(s) the KMS key's (if present) resource policy should be trivial (since it'd be a mirror of the S3 bucket).

So with this situation, it will be a little harder to implement than I had assumed in the opening message before seeing the L1 constructs irl.

I am not going to open a PR based on by branch because I fear it'd generate quite a bit of noise. But the following links should be sufficient to understand where it's at:

• My branch
• Creating an Origin Access Control docs
• S3 Origin TS file (It's bind method is particularly of interest)
• OriginBindOptions
• Where bind gets called