CloudFront Origin Access Control L2

[AMZN-hgoffin]

Description

The CloudFront L2 constructs in the CDK only support Origin Access Identity, which is considered legacy (AWS is allergic to "deprecated", but it's definitely deprecated!) and will not work in any new S3 regions going forward.

CloudFormation L1 includes support for Origin Access Control, but using this with the L2 constructs is difficult or impossible because the existing code always enables Origin Access Identity, which is incompatible.

In addition, existing customers have reported struggles with Origin Access Identity in combination with the S3Origin L2 construct as it has a secret behavior: it attempts to adjust the resource policy of the origin bucket to grant access to CloudFront. Unfortunately this attempt is not compatible with buckets which use ACL and not IAM, and there is no way to prevent this behavior. Also, when a bucket is imported by name or attributes, the S3Origin attempt to modify policy silently fails, and there is no warning about this (neither in documentation, at build time, or during deployment).

Origin Access Control will make this situation more acute, because OAC has a wider range of possible permissions (OAC can support PUT/POST operations, but customers will usually not want to grant write permissions!) and is simultaneously less flexible for deployment (due to circular dependencies between bucket policy and the distribution ID, which is an output of the distribution). Buckets in the same stack can have policy applied automatically, but buckets which are imported across stacks cannot. CDK users will need a way to control the level of automatic permission granting, both to permit read-write access when desired, and also to disable the automatic grant in order to break circular dependencies.

This proposal has two parts:

• Create L2 Origin Access Control constructs which mirror the existing Origin Access Identity constructs
• Add a new option on S3Origin and CloudFrontWebDistribution to control the automatic granting of permissions, for both OAI and OAC. It will default to automatic read-only permissions, which matches the existing behavior for OAI.

Roles

Role	User
Proposed by	@AMZN-hgoffin
Author(s)	@AMZN-hgoffin
API Bar Raiser	@alias
Stakeholders

See RFC Process for details

Workflow

• Tracking issue created (label: status/proposed)
• API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
• Kick off meeting
• RFC pull request submitted (label: status/review)
• Community reach out (via Slack and/or Twitter)
• API signed-off (label api-approved applied to pull request)
• Final comments period (label: status/final-comments-period)
• Approved and merged (label: status/approved)
• Execution plan submitted (label: status/planning)
• Plan approved and merged (label: status/implementing)
• Implementation complete (label: status/done)

---

Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

[AMZN-hgoffin]

References:
aws/aws-cdk#21771 (P1 CDK issue)
aws/aws-cdk#24861 (exploratory draft PR, includes additional functionality for a cross-stack policy-editing construct which is not part of this RFC)

[cornelcroi]

I really need OAC support as I'm preparing to open source a project and having the tweak mentioned in the issue aws/aws-cdk#21771 is not too clean even if it works.

[antstanley]

Is there any movement on this? The original issue aws/aws-cdk#21771 is over 15 months old. This RFC has over 240 👍🏼 and 16 ❤️ indicating a ton of folks want this change.

OAC enables additional functionality in CloudFront, in particular the ability to PUT and POST to S3 via CloudFront, and is the AWS recommend way to implement S3 access via CloudFront.

The RFC and the associated PR (aws/aws-cdk#24861) appear to have been abandoned. Using the L1 construct is non-starter for many folks as it introduces a circular dependency, and requires removing a hardcoded OAI the existing constructs appear to introduce.

[mattiLeBlanc]

@AMZN-hgoffin Hi, what is that status of this?
I am trying to setup a secondary bucket for assets in my Cloudfront distribution that is already using a bucket hosting a static angular app.
I am tryingto move away from OAI, but I can't find the constructs to help me.
I can create my control:

    const s3DocumentControl = new CfnOriginAccessControl(this, `${this.props.applicationName}DocumentControl`, {
      originAccessControlConfig: {
        name: `${this.props.applicationName}-documents`,
        originAccessControlOriginType: 's3',
        signingBehavior: 'no-override',
        signingProtocol: 'sigv4'
      }
    })

but I can't add it to my s3OriginSource, that only supports originAccessIdentity.

Also, I am unable to update the policy of this existing s3 bucket and give cloudfront permission to execute getObject from it.
I read in another post that you can't do this in an existing bucket, unless I use a post deployment SDK command or something like that.

Are there any plans to make this a bit better?

[glc-omid]

@AMZN-hgoffin Hi, what is that status of this? I am trying to setup a secondary bucket for assets in my Cloudfront distribution that is already using a bucket hosting a static angular app. I am tryingto move away from OAI, but I can't find the constructs to help me. I can create my control:

    const s3DocumentControl = new CfnOriginAccessControl(this, `${this.props.applicationName}DocumentControl`, {
      originAccessControlConfig: {
        name: `${this.props.applicationName}-documents`,
        originAccessControlOriginType: 's3',
        signingBehavior: 'no-override',
        signingProtocol: 'sigv4'
      }
    })

but I can't add it to my s3OriginSource, that only supports originAccessIdentity.

Also, I am unable to update the policy of this existing s3 bucket and give cloudfront permission to execute getObject from it. I read in another post that you can't do this in an existing bucket, unless I use a post deployment SDK command or something like that.

Are there any plans to make this a bit better?

I did not try yet but someone shared a working snippet
aws/aws-cdk#21771 (comment)

[yashjain24]

Hi, Is there any ETA when this feature will be available in aws-cdk ?

[antstanley]

Hey Folks! AWS announced support for Origin Access Control for Lambda Function URLs and AWS Elemental MediaPackage Origin yesterday.

Please can we get some movement on OAC being supported by aws-cdk-lib. This is getting beyond embarrassing. It's actively making workloads less secure.

The original issue aws/aws-cdk#21771 is now 20 months old.

[gracelu0]

Hi everyone,

As mentioned in the comment on the original issue, we are actively working on this feature! Going forward, progress will be tracked using #617 so I will be closing this issue to prevent duplicate work and confusion. Thank you!