amazon-web-services - 绕过云端 S3 身份验证中包含 x-amz-cf-id header 的需要

Question

我有一个不完全正统的 CF->S3 设置。这里的相关组件是:

Cloudfront 分发与 origin s3.ap-southeast-2.amazonaws.com

添加 S3 授权(版本 2)查询字符串(使用函数使用的 S3 策略签名)的 Lambda@Edge 函数(原始请求)。

Lambda 返回的请求是完全正确的。如果我记录 uri、主机和查询字符串，我会得到我请求的文件。但是，如果我直接通过 Cloudfront 链接访问它，请求将失败，因为它不再使用 AWSAccessKeyID ，而是选择使用 x-amz-cf-id (但使用相同的签名、Amz-Security-Token 等)。 更正:它可能不会替代，但需要补充。

我知道是这种情况，因为我已经退回了 StringToSign和 SignatureProvided .这些都匹配 Lambda 响应，除了 AWSAccessKeyID已替换为 x-amz-cf-id .

这显然是一个非常具体的问题。我可能不得不考虑改造这个架构，但我不希望这样做。有几个要求导致我放弃了这种不完全常规的设置。

Answer 1

我相信AWSAccessKeyID => x-amz-cf-id替换是两种机制的结果:

首先，您需要配置 CloudFront 以将查询参数转发到源。没有它，它将剥离所有参数。如果您使用 S3 签名的 URL，请确保还根据所有参数进行缓存，否则您最终将没有任何访问控制。

二、CloudFront附上x-amz-cf-id到不去 S3 源的请求。您可以在 CloudFront 控制台上仔细检查源类型，并且您需要确保它被报告为 S3。我有一个 blog post详细描述它。

但是使用 Lambda@Edge 将 S3 签名添加到所有请求中会破坏目的。如果您想保持存储桶私有(private)并且只允许 CloudFront 访问它，那么请使用原始访问身份，这正是用例的需要。