Question

我理解这是一个常见问题，但我对他们的解决方案没有成功。

我在S3上托管了两个网站：

bucket.ca（允许*.bucket.ca）
dev.bucket.ca（允许dev.bucket.ca）

它们可以公开访问，但是我不希望任何人访问其S3 URL。所以我用StringEquals编辑了存储桶策略。

每个水桶一个：

arn:aws:s3:::bucket.ca/* arn:aws:s3:::dev.bucket.ca/*

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadForGetBucketObjects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::dev.bucket.ca/*",
            "Condition": {
                "StringEquals": {
                    "aws:UserAgent": "random-hash"
                }
            }
        }
    ]
}

这是令人沮丧的部分。每次我对Cloudfront进行更改或对存储桶进行更改时，其行为都是高度不一致的。

dev.bucket.ca似乎按预期运行，其S3网址导致访问被拒绝，我可以访问其任何子路径dev.bucket.ca/*。因此，我为bucket.ca复制了此配置，但结果始终是403。

使用dev.bucket.ca进行检查，我不再能够访问其子路径。 dev.bucket.ca/404的结果为403。

是否有可靠的方法来测试S3和Cloudfront配置？每次编辑Cloudfront时，更改更新的速度都很慢。我是否应该每次都清除浏览器缓存并重新打开隐身模式以获得更可靠的结果？

Answer 1

为调试此问题，我还原了策略以允许所有公共用户使用

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadForGetBucketObjects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::dev.bucket.ca/*",
        }
    ]
}

此政策完全适用于bucket.ca和dev.bucket.ca。因此，看来这是我的条件。

"aws:UserAgent": "random-hash"

事实证明，自定义标头必须为User-Agent，而不是UserAgent。因此，Cloudfront应该使用User-Agent作为其自定义标头，并使用S3策略使用UserAgent。

在部署Cloudfront之后，我对此进行了测试，并且两个网站均正常工作。 S3存储桶也无法访问，这很好。

限制S3静态网站访问Cloudfront

1 个答案: