Для доступа к #s3 можно использовать #iam, #bucket_policy и #bucket_acl - что же лучше использовать?
Если коротко, то всегда лучше выбирать #IAM.
Когда не получается или нужен как раз #resource_based подход - выбираем #bucket_policy (без него не обойтись для случаев #cross_account).
Использовать ACL не стоит ни разу - это и старое и неудобное.
Если коротко, то всегда лучше выбирать #IAM.
Когда не получается или нужен как раз #resource_based подход - выбираем #bucket_policy (без него не обойтись для случаев #cross_account).
Использовать ACL не стоит ни разу - это и старое и неудобное.
Amazon
IAM Policies and Bucket Policies and ACLs! Oh, My! (Controlling Access to S3 Resources) | Amazon Web Services
September 11, 2023: This post has been updated. Updated on July 6, 2023: This post has been updated to reflect the current guidance around the usage of S3 ACL and to include S3 Access Points and the Block Public Access for accounts and S3 buckets. Updated…
Итак, чтобы попробовать, находим рутовые доступы к двум аккаунтам. Логинимся и в консоли жмём на своём имени My Security Credentials -> подтверждаем, что в своём уме и не хотим #IAM (Continue to Security Credentials) -> Access keys (access key ID and secret access key). Там создаём себе новые и прописываем в виртуалке.
В консоле одного из них создаём бакет. Закидываем файл. Проверяем из второго аккаунта - доступа, логично, нет. Попробуем расшарить.
Когда мы переизобретали #S3, то у нас клиенты - это были как юзеры в линукс. Клиенты логинятся через свою почту, но под капотом, понятно, у них должны быть однозначные айдишники. Это и есть Canonical ID - 64-байтный единый айдишник для всего AWS аккаунта (а не только S3). В случае же S3 именно этот айдишник выступает в качестве идентификатора owner-а для всех бакетов и файлов им созданных.
Поэтому, чтобы оперировать с доступом на S3 нужно иметь эти айдишники - амазоновское апи работает именно с ними, определяя доступ в структуре ACL. Получить их можно в консоли (из-под рута) My Security Credentials -> Account identifiers -> Canonical User ID или выполнив команду
Итак, в консоли в бакете на закладке Access Control List жмём Add account, вбиваем Canonical ID второго аккаунта и жмём галки Read и Write. Пробуем из другого аккаунта - в бакет файлы прекрасно входят и выходят. Что и требовалось доказать - оно работает. Так и было задумано - у бакета никаких полиси, а кросс-аккаунтный доступ есть. С поправкой, опять же, на руты, но других сущностей тогда и не было.
Вместо указания Canonical ID, Амазон, пытаясь как-то облегчить работу с апишкой, позволял указывать вместо него почту юзера (снова именно рута - т.е. на который регистрировался аккаунт). Это в частности, позволяла путём подбора, выяснить, зарегистрирован ли такой ящик на амазоне. Например, на картинке подставлен ящик создаля Амазона Jeff Barr и видно из ответа Амазона, что у него даже несколько аккаунтов.
Но в общем случае в ответе будет ошибка, что такого ящика нет. Даже если он у вашего аккаунта точно есть - это должен быть старый аккаунт, т.к. с 2014-го года эту фичу преобразования ящиков в Canonical ID (под капотом-то то именно он) отключили - ищите древней, а лучше просто указывайте айдишник.
Итого, чтобы пользоваться S3 bucket ACL - нужны руты и только руты. IAM не используется от слова совсем - руту плевать на любые наcтройки IAM, т.к. он просто никогда не заходит в эту апишку, ведь он более древняя сущность и потому работает напрямую с Амазоном. Однако он может взаимодействовать с Bucket Policy, но это уже другая история.
#bucket_acl
В консоле одного из них создаём бакет. Закидываем файл. Проверяем из второго аккаунта - доступа, логично, нет. Попробуем расшарить.
Когда мы переизобретали #S3, то у нас клиенты - это были как юзеры в линукс. Клиенты логинятся через свою почту, но под капотом, понятно, у них должны быть однозначные айдишники. Это и есть Canonical ID - 64-байтный единый айдишник для всего AWS аккаунта (а не только S3). В случае же S3 именно этот айдишник выступает в качестве идентификатора owner-а для всех бакетов и файлов им созданных.
Поэтому, чтобы оперировать с доступом на S3 нужно иметь эти айдишники - амазоновское апи работает именно с ними, определяя доступ в структуре ACL. Получить их можно в консоли (из-под рута) My Security Credentials -> Account identifiers -> Canonical User ID или выполнив команду
aws s3api list-buckets, которая в JSON отдаст в Owner.ID.Итак, в консоли в бакете на закладке Access Control List жмём Add account, вбиваем Canonical ID второго аккаунта и жмём галки Read и Write. Пробуем из другого аккаунта - в бакет файлы прекрасно входят и выходят. Что и требовалось доказать - оно работает. Так и было задумано - у бакета никаких полиси, а кросс-аккаунтный доступ есть. С поправкой, опять же, на руты, но других сущностей тогда и не было.
Вместо указания Canonical ID, Амазон, пытаясь как-то облегчить работу с апишкой, позволял указывать вместо него почту юзера (снова именно рута - т.е. на который регистрировался аккаунт). Это в частности, позволяла путём подбора, выяснить, зарегистрирован ли такой ящик на амазоне. Например, на картинке подставлен ящик создаля Амазона Jeff Barr и видно из ответа Амазона, что у него даже несколько аккаунтов.
Но в общем случае в ответе будет ошибка, что такого ящика нет. Даже если он у вашего аккаунта точно есть - это должен быть старый аккаунт, т.к. с 2014-го года эту фичу преобразования ящиков в Canonical ID (под капотом-то то именно он) отключили - ищите древней, а лучше просто указывайте айдишник.
Итого, чтобы пользоваться S3 bucket ACL - нужны руты и только руты. IAM не используется от слова совсем - руту плевать на любые наcтройки IAM, т.к. он просто никогда не заходит в эту апишку, ведь он более древняя сущность и потому работает напрямую с Амазоном. Однако он может взаимодействовать с Bucket Policy, но это уже другая история.
#bucket_acl