Распределение AWS Cloudfront на основе корзины S3 с объектами кросс-аккаунта, получающими доступ запрещен - PullRequest
1 голос
/ 27 июня 2019

У меня есть два аккаунта (acc-1 и acc-2).
acc-1 содержит API, который обрабатывает загрузку файлов в контейнер acc-1 (назовем его upload). Загрузка запускает SNS для преобразования изображений или перекодирования видео. Полученные файлы помещаются в другое ведро в acc-1 (output), которое снова запускает SNS. Затем я копирую файлы (как пользователь api из acc-1) в их окончательную корзину в acc-2 (content).

content политика корзины в acc-2

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACC_1_ID>:user/api"
      },
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::content/*"
    }
  ]
}

api политика пользователя в acc-1

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::upload/*",
        "arn:aws:s3:::output/*",
        "arn:aws:s3:::content/*"
      ]
    }
  ]
}

Я копирую файлы, используя aws-sdk для nodejs и устанавливая ACL на bucket-owner-full-control, чтобы пользователи из acc-2 могли получить доступ к скопированным файлам в content, хотя пользователь api из acc-1 все еще владелец файлов.

Это все работает нормально - файлы хранятся в корзине content с доступом для владельца корзины и пользователя api.

Файлы из content корзины являются приватными для всех остальных и должны обслуживаться через дистрибутив Cloudfront.

Я создал новый дистрибутив Cloudfront для Интернета и использовал следующие настройки:

Имя домена происхождения: content
Исходный путь: /folder1
Ограничить доступ к корзине: yes
Идентификация доступа к источнику: create new identity
Предоставить разрешения на чтение на ведро: yes, update bucket policy

Это создало новую идентификацию доступа к источнику и изменило политику корзины на:

content политика ведра впоследствии

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACC_1_ID>:user/api"
      },
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::content/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <OAI_ID>"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::content/*"
    }
  ]
}

Но попытка получить доступ к файлам из корзины content внутри папки folder1 не работает при использовании URL-адреса Cloudfront:

https://abcdef12345.cloudfront.net/test1.jpg

Возвращает 403 «Доступ запрещен».

Если я загружаю файл (test2.jpg) из acc-2 напрямую в content/folder1 и пытаюсь получить к нему доступ, он работает ...!?

https://abcdef12345.cloudfront.net/test2.jpg

За исключением разных владельцев, test1.jpg и test2.jpg кажутся полностью идентичными.

Что я делаю не так?

1 Ответ

0 голосов
/ 28 июня 2019

К сожалению, это ожидаемое поведение. OAI не могут получить доступ к объектам, принадлежащим (созданным) другой учетной записью, поскольку bucket-owner-full-control использует необычное определение «full», которое исключает грантовые правила политики для участников вне вашей учетной записи AWS, а канонический пользователь OAI технически находится за пределами ваш аккаунт AWS.

Если другая учетная запись AWS загружает файлы в вашу корзину, эта учетная запись является владельцем этих файлов. Политики Bucket применяются только к файлам, которыми владеет владелец Bucket. Это означает, что если другая учетная запись загружает файлы в ваше хранилище, политика хранилища, созданная для вашего OAI, не будет оцениваться для этих файлов.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-granting-permissions-to-oai

...