首页 文章

使用未签名的URL访问公共读取S3对象时，我是否应该收到Cloudfront'MissingKey'错误？

提问于
浏览 次
0

假设我正在构建一个Dropbox克隆：Filebox . 我用S3存储了所有用户的文件，我使用Cloudfront作为我的CDN .

所以我有一个受限制的S3存储桶（ files.filebox.com ），其存储桶策略允许 s3:GetObject 仅允许我通过Cloudfront创建的Origin Access Identity . 这会强制所有'file'请求通过Cloudfront，并禁止任何人通过S3 URL访问文件 .

files.filebox.com的存储桶策略

{
    "Version": "2008-10-17",
    "Id": "AllowCloudfrontGet",
    "Statement": [
        {
            "Sid": "AllowCloudFrontGet",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXXXXXXXXXX"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::files.filebox.com/*"
        }
    ]
}

意外行为

让's say, for simplicity sake, I' m存储所有具有 public-read 的固定ACL的文件 .

所以这个URL应该工作：
https://files.filebox.com/<userID>/some-file.txt

但这个应该导致403： https://s3.amazonaws.com/files.filebox.com/<userID>/some-file.txt

但我看到了相反的结果 . S3 URL工作正常，但是通过Cloudfront的 files.filebox.com URL正在抛出 MissingKey 错误 .

files.filebox.com URL确实有效，但仅当我对URL进行签名时，即使对于具有 public-read 的ACL的对象也是如此 .

问题

Given that the bucket policy only allows s3:GetObject for the CF OAI, shouldn't the S3 URL fail with a 403, even if the object has a public-read ACL?
除了模糊的语言之外，我在文档中找不到任何关于此的信息，似乎表明对于任何未通过Cloudfront发出的请求，受限制的存储桶应为403 .

When I set the ACL of an object to public-read does that not obviate the need to sign the Cloudfront URL, even on a restricted bucket?

Do I need to add another Statement to my Bucket Policy that allows unsigned URL access to public-read objects?
我尝试了这个，但它没有确定如何写这样的 Statement 甚至......

How do I truly deny any requests that come through via the S3 URLs?
我想为S3 URL上的任何请求抛出403，即使对于ACL为 public-read 的对象也是如此 .

amazon-web-services amazon-s3 amazon-cloudfront pre-signed-url

1 回答

  • 2

    假设存储桶策略只允许s3：GetObject用于CF OAI，那么即使对象具有公共读取ACL，S3 URL也不应该失败;

    编号 public-read 表示直接从S3允许公开（未经身份验证的）读取 . 由于存储桶拥有者允许使用 public-read ACL上载对象，因此即使没有存储桶策略，该对象也是桶拥有者默认同意的公共对象 .

    对象ACL和存储桶策略 Allow 选项是附加的 . 如果你不公开 .

    当我将对象的ACL设置为public-read时，即使在受限制的存储桶上，这也不会消除签署Cloudfront URL的需要吗？

    不，它没有 . CloudFront不评估对象ACL . 它根据缓存行为设置决定是否要求身份验证 . 如果配置为要求对给定路径模式进行身份验证，则需要进行身份验证，无论CloudFront背后的实体是S3还是其他实体 . 如果CloudFront拒绝访问，则甚至不会向S3发送任何请求 .

    我是否需要在我的Bucket Policy中添加另一个Statement，允许对公共读取对象进行未签名的URL访问？

    否 . 存储桶策略中的任何内容都不会修改CloudFront的前端身份验证的行为 .

    典型的方法是将某些前缀指定为公共前缀而将其他前缀指定为公共前缀，并使用适当的匹配路径模式配置CloudFront缓存行为，例如， /public/* 可能配置为不需要签名的URL，但 /private/* 可能需要它们 .

    此设置称为Restrict Viewer Access，并设置为“缓存行为”级别（因此位于“路径模式”级别） .

    我想为S3 URL上的任何请求抛出403，即使对于具有公共读取ACL的对象也是如此 .

    将对象ACL设置为 public-read 意味着，通过定义，该对象应该可以直接从S3存储桶 endpoints 访问而无需凭据 . 没有更多，没有更少 .

    从这个角度来看，你所说的是类似于说"I'd like to prevent someone from stealing my car, even though I am planning on leaving the keys in the ignition."它可以做到，但是它正在解决错误的问题......而且它很快变得复杂，因为你必须采用像 Deny 这样的策略来包含异常不仅适用于CloudFront，也适用于您自己的控制台以及访问存储桶的应用程序，角色等 .

    原始访问标识的要点是，CloudFront具有一组凭据，它可以在向存储桶发送请求时使用，无论CloudFront是否要求用户提供身份验证凭据 . 有了OAI，就没有理由在对象ACL上使用 public-read .

    回复于

相关问题