I have set up a simple static web site on AWS as an exercise.
My site is contained inside an AWS S3 Bucket and it is structured as such:
/
├─ releases/
│ ├─ index.html
│ ├─ index.js
│ ├─ index.css
├─ secret.html
The bucket policy is configured to allow access only for releases dir, and disallow access to root dir where secrets secret.html reside.
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::www.aws-serverless.tc/releases/*"
}
]
}
As an additional feature, I want to use CloudFront to make my website more solid and secure. I have added all the configurations necessary.
Now my site is accessible both through the
http://*.s3-website.eu-north-1.amazonaws.com
URL, and the
https://*.cloudfront.net
URL.
The thing is, I don’t want the website to be accessible through the s3-website url, but only through the cloudfront url.
I’ve tried this configuration (I replaced the arns with my s3 bucket arn and cloudfront arn respectivelly):
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowCloudFrontServicePrincipalReadOnly",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::<S3 bucket name>/releases/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
}
}
}
}
However when I replace the old configuration with it, the s3-website returns 403 which is correct. But the CloudFront site returns 403 as well.
I got the configuration from Amazon Docs, any idea why it doesn’t work as expected?
5
Your scenario seems like an ideal use case for S3 Access Points. You would create one access point which has an access point policy that limits the access to just the /releases path. You would also make this policy limit access to only CloudFront, as you have shown.
You would create another access point with a different policy and broader access to be used for those who needs to access secrets.
Then, you would define a bucket policy that effectively delegates all access control to the access points, as outlined in https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-policies.html#access-points-delegating-control. That link gives this example:
{
"Version": "2012-10-17",
"Statement" : [
{
"Effect": "Allow",
"Principal" : { "AWS": "*" },
"Action" : "*",
"Resource" : [ "Bucket ARN", "Bucket ARN/*"],
"Condition": {
"StringEquals" : { "s3:DataAccessPointAccount" : "Bucket owner's account ID" }
}
}]
}
Or you could deny all access that does not come through an access point using a policy similar to this:
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
"Condition": {
"StringNotEquals": {
"s3:DataAccessPointAccount": "YOUR_ACCOUNT_ID"
}
}
}
With that configuration, access that comes through the default S3 URL will be denied, while access that comes using one of the access points will be governed by the corresponding access point policy. Lastly, you set your CloudFront origin to use the S3 access point you created for /releases. So while this may not directly answer your question, this may be a more elegant solution. AWS says
You can delegate access control for a bucket to the bucket’s access
points…Thus, all access to this bucket is controlled by the policies
attached to its access points. We recommend configuring your buckets
this way for all use cases that don’t require direct access to the
bucket.