CloudFront Origin Access Control L2
AMZN-hgoffin opened this issue · comments
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 | |
| 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-approvedapplied 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.
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)