-
Notifications
You must be signed in to change notification settings - Fork 83
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
RFC 617: CloudFront S3 Origin Access Control L2 #624
Conversation
9e690c1
to
5dc844c
Compare
text/0617-cloudfront-oac-l2.md
Outdated
|
||
## Migrating from OAI to OAC | ||
|
||
If you are currently using OAI for your S3 origin and wish to migrate to OAC, first set the feature flag `@aws-cdk/aws-cloudfront:useOriginAccessControl` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!!!
Removing the final commenting period because we're not quite there yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this took me a very long time and I left quite a lot of comments. Given that I want to say that I think this is a very good start and this this is a quite complex set of functionality to navigate given the limitations and pre-existing functionality that needs to be worked around.
text/0617-cloudfront-oac-l2.md
Outdated
|
||
### CHANGELOG | ||
|
||
`feat(cloudfront): origin access control L2 construct` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't quite what this RFC proposes. According to the CloudFormation OriginAccessControl documentation, there are four types. While it is not necessarily invalid to scope this change down to just S3, the design must be extensible to all four types. My feedback below will be based off that requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, while I won't ask for a full design on the other three types, I'd like a section briefly discussing the expected user contract for them. No implementation details or anything further is needed on those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not actually sure that we have implementations for Origin
for MediaPackage
or MediaStore
but they might(?) fall under one of the other origin types. I'm kind of unclear on that because the origin types we have implemented don't actually align with what I see listed on the Origin property page for the Distribution resource. Can we get clarification from the CloudFront team on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we update the changelog to reflect that this is only for the S3 origin type?
}); | ||
} | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I glazed over everything between my last comment and this one because of the comment that I didn't think the custom resource was the way to go here.
text/0617-cloudfront-oac-l2.md
Outdated
|
||
### CHANGELOG | ||
|
||
`feat(cloudfront): origin access control L2 construct` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we update the changelog to reflect that this is only for the S3 origin type?
Pull request has been modified.
ff2d9e6
to
a68bc62
Compare
a68bc62
to
656eb86
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that you took the feedback here from myself and Calvin but I think we pushed it a little too far in the opposite direction of where you were starting from.
S3BucketOriginWithOAI
, S3BucketOriginWithOAC
, and S3BucketOriginPublic
classes in addition to S3StaticWebsiteOrigin
seems a bit overkill and I think we can simplify this a bit more.
Nearly no notes to SigningBehavior
, SigningProtocol
, or Signing
, but the rest feel like we could be abstracting more away from the user and simplifying the contract a bit.
What I'm thinking is something more along the lines of separating out the two types of bucket origins for better clarity (which you totally did) but utilizing static function to minimize nesting of props. Something like:
/**
* Props for adding OAC
*/
export interface S3OriginAccessControlProps extends cloudfront.OriginProps {
/**
* @default - SIGV4_ALWAYS
*/
signing?: Signing
}
export abstract class S3BucketOrigin {
/**
* Static function to create the OAC with a little bit of an example of how this
* could potentially be implemented.
*/
public static withOriginAccessControl(bucket: IBucket, props?: S3OriginAccessControlProps): cloudfront.IOrigin {
return new class implements cloudfront.IOrigin {
bind(scope: Construct, options: cloudfront.OriginBindOptions): cloudfront.OriginBindConfig {
// Create the OAC here and return the config
}
}();
}
/**
* We hope people won't use this but we can't remove the functionality altogether
*/
public static withOriginAccessIdentity(bucket: IBucket, identity: cloudfront.IOriginAccessIdentity): cloudfront.IOrigin {
// Samesies again
}
/**
* Unideal, but still technically an option. Make them have to declare it manually
*/
public static withBucketDefaults(bucket: IBucket, props: cloudfront.OriginProps): cloudfront.IOrigin {
// Samesies as above
}
constructor() { }
}
/**
* For namespace reservation only
*/
export interface S3StaticWebsiteOriginProps extends cloudfront.OriginProps {}
export class S3StaticWebsiteOrigin implements cloudfront.IOrigin {
constructor (bucket: IBucket, props?: S3StaticWebsiteOriginProps) { }
bind(scope: Construct, options: cloudfront.OriginBindOptions): cloudfront.OriginBindConfig {
// Use this to pass the scope so that the user doesn't have to provide it
}
}
So, in practice, this looks something like:
const bucket = new Bucket(this, 'bucket');
new cloudfront.Distribution(this, 'newDist', {
defaultBehavior: {
origin: S3BucketOrigin.withOriginAccessControl(bucket),
},
});
new cloudfront.Distribution(this, 'newDist', {
defaultBehavior: {
origin: S3BucketOrigin.withOriginAccessControl(bucket, { signing: Signing.SIGV4_NO_OVERRIDE }),
},
});
new cloudfront.Distribution(this, 'newDist', {
defaultBehavior: {
origin: S3BucketOrigin.withOriginAccessIdentity(bucket, cloudfront.OriginAccessIdentity.fromOriginAccessIdentityId(this, 'OAIResource', 'OAI')),
}
});
This comment covers my overall feedback so I'll avoid adding comments to this extent in every location where the proposed contract is different.
``` | ||
|
||
> Note: If your bucket previously used OAI, you will need to manually remove the policy statement | ||
that gives the OAI access to your bucket from your bucket policy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be a little more to it than that but the specifics of migration don't necessarily need to be covered here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you elaborate on what is missing as part of migration?
Pull request has been modified.
b0ce6b2
to
f90c1d4
Compare
Hi all! This RFC has been approved by the API Bar Raiser and will remain open for a week for any final comments. If no further comments we will merge in a week. Thank you! |
### Issue # (if applicable) n/a ### Reason for this change Note: This PR is a WIP, not merging to the main branch. Merging to a feature branch first to facilitate smaller PR reviews. Support OAC for S3 origins, see [RFC](aws/aws-cdk-rfcs#624) for more details ### Description of changes - Deprecate `CloudFrontWebDistribution` in favour of existing class `Distribution` - Add new abstract base class `OriginAccessControlBase` and subclass `S3OriginAccessControl` - Deprecate `S3Origin` in favour of new classes `S3BucketOrigin` and `S3StaticWebsiteOrigin` - Add new abstract class `S3BucketOrigin` - 3 static functions for instantiating S3 origin with OAI, OAC and no origin access control (using bucket defaults) - Add new class `S3StaticWebsiteOrigin` - Update README for `cloudfront` and `cloudfront-origins` ### Description of how you validated changes - `integ.s3-origin-oac`: basic use case setting up a distribution with an S3 origin with OAC, using assertions to check the distribution has the oac configured and the oac has the expected default properties - unit tests for `S3OriginAccessControl` (more tests to follow in coming PRs) ### 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*
No new comments, merging the RFC now as the final comment period has passed. |
This is a request for comments about CloudFront Origin Access Control L2 for S3 origins. See #617 for
additional details.
APIs are signed off by @comcalvi .
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license