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

Question

将多个 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 身份的读取访问权限。 从查看文档看来， 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版本进行了尝试，但它没有提供访问权限。 我究竟做错了什么？ 还是有更好的方法？

Answer 1

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

鉴于此，我认为它在这里不适用，并且s3:GetObject没有提到它是一种可能性——这个动作似乎只支持少数非全局条件键，所有这些键都是特定于 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 账户的一部分——它们是一个外部实体。¹鉴于此，似乎不太可能有一种方式来表达“所有我的OAI”在一份政策声明中。

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

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

---

¹此断言的理由：即使x-amz-acl: bucket-owner-full-control应用于 object，OAI 也无法访问由具有写入权限的不同 AWS 账户创建的存储桶中的对象： “如果另一个 AWS 账户将文件上传到您的存储桶，则该账户是这些文件的所有者。存储桶策略仅适用于存储桶所有者拥有的文件。这意味着如果另一个账户将文件上传到您的存储桶，则您的存储桶策略为您的 OAI 创建的文件不会针对这些文件进行评估。” 如果您的存储桶策略明确授予不同账户中的 IAM 用户读取访问权限，则情况完全相同——当 object 也由用户创建时，存储桶策略无法将读取权限委派给同一账户之外的用户从帐户外部。 如果存储桶策略允许，您账户中的用户可以访问此类对象。

Answer 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 -状态。

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