为任何 Cloudfront 源访问身份添加 S3 存储桶策略答案

【问题标题】：Adding S3 Bucket Policy for any Cloudfront Origin Access Idenity为任何 Cloudfront 源访问身份添加 S3 存储桶策略
【发布时间】：2021-02-26 06:27:07
【问题描述】：

对一个存储桶使用多个 CloudFront 效果不佳，因为我可以在 CloudFormation 中授予访问权限的唯一方法是在模板中添加 BucketPolicy。对于多个应用程序/模板，这将始终覆盖整个存储桶策略以添加S3 Origin Access Identity 的权限。

    S3OriginIdentity:
        Type: 'AWS::CloudFront::CloudFrontOriginAccessIdentity'
        Properties:
          CloudFrontOriginAccessIdentityConfig:
            Comment: S3 Origin Identity
    S3OriginIdentityS3ReadPolicy:
      Type: "AWS::S3::BucketPolicy"
      Properties:
        Bucket: my-bucket
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
          - Sid: my-cloudfront-read-access
            Action:
              - s3:GetObject
            Effect: Allow
            Principal:
              CanonicalUser:
                Fn::GetAtt: S3OriginIdentity.S3CanonicalUserId
            Resource: arn:aws:s3:::my-bucket/path/*

为了解决这个问题，我想到可以使用存储桶策略中的条件来授予对任何 Cloudfront 身份的读取访问权限。从the documentation 看来，aws:SourceArn 或 aws:PrincipalArn 应该可以解决问题。这是我尝试的示例策略。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": 1,
        "Action": [
            "s3:GetObject"
        ],
        "Effect": "Allow",
        "Resource": "arn:aws:s3:::my-bucket/*",
        "Condition": {
            "ArnLike": {
                "aws:SourceArn": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity*"
            }
        },
        "Principal": "*"
    }]
}

当我使用aws:PrincipalArn 时，控制台甚至不允许我保存它（通用的Access Denied），但我尝试使用上面的aws:SourceArn 版本，它没有提供访问权限。我究竟做错了什么？还是有更好的方法？

【问题讨论】：

标签： amazon-web-services amazon-s3 amazon-cloudformation amazon-cloudfront

【解决方案1】：

aws:SourceArn 被列为“仅可用于某些服务”，并且不是指委托人，而是指作为操作源的资源，例如 SQS 队列策略中的 SNS 主题或 Macie 策略中的 S3 存储桶。

鉴于此，我认为它在这里不适用，并且s3:GetObject 没有提到它是一种可能性——这个动作only appears to support 少量非全局条件键，所有特定于 S3：s3:ExistingObjectTag/<key>、s3:authtype、s3:signatureage、s3:signatureversion、s3:x-amz-content-sha256。

aws:PrincipalArn 是一个全局条件键，所以看起来它可能有效，但我建议你很幸运它没有。如果有，那么您会将您的存储桶暴露给所有 AWS 账户中所有 CloudFront 分配的所有源访问身份。 “访问被拒绝”错误是意外的，但可能源于您缺乏对 arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity* 的权限这一事实，这是有道理的，因为它不属于您的账户 - OAI 由 CloudFront 分配给您的账户，但它们不是'严格来说，不是您的 AWS 账户的一部分——它们是一个外部实体。¹鉴于此，似乎不太可能有一种方法来表达“所有 my OAI”政策声明。

我建议让多个 CloudFront 分配访问单个存储桶的最直接方法是创建一个 OAI 并配置您的多个 CloudFront 分配以使用它。单独的 OAI 和单独的存储桶策略授权不仅笨重，而且无法扩展——存储桶策略的大小限制在 ~20KB。

但如果这是您想要的方向，似乎可以使用Lambda-Backed Custom Resource。这里的想法是创建一个 Lambda 函数，该函数将编辑存储桶策略并将新 OAI 附加到包含已添加 OAI 的 Principal 数组中。（存储桶策略中的Principal 可以是标量或数组）。这样做的危险在于它是一个微妙的操作——存储桶策略没有并发保护，因此如果其中两个堆栈尝试同时有效地修改策略（获取、编辑、放置），那么其中一个将看到它的更新被忽略，因为它们被另一个覆盖。（最终按此顺序的并发操作——读取#1、修改#1、读取#2、修改#2、写入#1、写入#2——导致写入#1的更改丢失，因为写入#2存储了数据它基于 Read #2，与 Read #1 相同。）

¹此断言的理由：OAI 无法访问由对您的存储桶具有写入权限的不同 AWS 账户创建的存储桶中的对象，即使 x-amz-acl: bucket-owner-full-control 应用于对象："If another AWS account uploads files to your bucket, that account is the owner of those files. Bucket policies only apply to files that the bucket owner owns. This means that if another account uploads files to your bucket, the bucket policy that you created for your OAI will not be evaluated for those files." 完全相同如果您的存储桶策略明确授予不同账户中的 IAM 用户读取访问权限，则事情是正确的 - 当对象也是由来自外部的用户创建时，存储桶策略无法将读取权限委派给同一账户之外的用户帐户。如果存储桶策略允许，您帐户中的用户可以访问此类对象。

【讨论】：

我注意到 OAI ARN 没有通常的 aws:<service>:<accountId>:<region> 模式，并认为它很奇怪，但没有放在一起就意味着它适用于任何 OAI。作为一般政策绝对不好。由于这个存储桶已经超出了应用程序的范围，因此策略和 OAI 也应该是合理的。我肯定被困在我已经拥有它的方式上，非常感谢你像你一样布置它。

【解决方案2】：

我知道这是一个老问题，但我遇到了类似的问题。

在使用 aws:PrincipalArn 时，我至少可以对 AccessDenied 错误有所了解。就我而言，这是因为我的 S3 存储桶启用了阻止公共策略，并且 aws:PrincipalArn 条件不足以成为非公共委托人。可以在这里找到所需的条件https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-policy-status。

我无法解决的是，在 Terraform 中似乎无法查询以前创建的 OAI。因此，如果我在一个模块中创建 OAI、S3 存储桶和策略，我以后将无法为 CloudFront 分配获取该 OAI。

【讨论】：