Привет! Сегодня хотим рассказать о, как использовать бакеты, хранить данные, настраивать политики и управлять доступом на данные при работе c объектным хранилищем S3.
S3 — это не иерархическая файловая система, а всего лишь хранилище ключей и значений, хотя ключ часто используется как путь к файлу для организации данных. Чтобы разместить файл в объектном хранилище S3, его необходимо поместить в бакет. Бакет (bucket — ведро) — это сущность для организации хранения в хранилище.
1.1 К имени бакета применяются следующие требования:
длина имени от 3 до 63 символов;
может содержать только латинские символы;
может состоять только из строчных букв, цифр, точек (.) и дефисов (-);
должно начинаться и заканчиваться только буквой или цифрой;
не должно содержать две смежные точки;
не не должно быть в формате IP-адреса;
не должно начинаться с префикса xn--;
не должно заканчиваться на -s3alias.
Точки и дефисы допускаются, но не во всех случаях. При некоторых дополнительных функциях это может вызывать проблемы совместимости. Мы рекомендуем избегать использования точек (.)
Примеры имён бакета:
Допустимы и соответствуют требованиям:
my-bucket-name
mybucket1
my-bucket-name-2022
Допустимы, но не рекомендуются для использования:
docexamplewebsite.com
www.docexamplewebsite.com
my.example.s3.bucket
Недопустимы:
doc_example_bucket (содержит подчеркивание)
DocExampleBucket (содержит заглавные буквы)
doc-example-bucket- (заканчивается дефисом)
1.2 Ограничения по бакету:
имя должно быть уникально во всем кластере Object Storage;
для каждого пользователя в группе можно создать до 100 бакетов;
допустимый максимальный размер одного объекта загрузки — 4 Гб, для загрузки больших объектов можно использовать технологию multipart upload.
1.3 Обращение к бакету
Для доступа вы можете использовать протоколы HTTP (s3.objstor.cloud4y.ru) или HTTPS (s3.objstor.cloud4y.ru)
https://s3.objstor.cloud4y.ru/<bucket>?<parameters>http://<bucket>.s3.objstor.cloud4y.ru?<parameters>
Доступ по HTTPS возможен только по URI формату.
1.4 Организация хранения данных в бакете
Хранилище S3 не обладает иерархической файловой системой, как в Unix. Файловая система в bucketе S3 плоская. Кроме того, в хранилище S3 нет такого понятия как файл или каталог, здесь есть «объекты».
Однако в бакете S3 можно создать некоторое подобие файловой системы, используя префиксы и разделители для организации хранящихся данных.
Каждому объекту можно назначить имя ключа. Имя ключа имеет префикс. Префикс — это строка символов в начале имени ключа объекта. Префикс может быть любой длины в зависимости от максимальной длины имени ключа объекта. Однако префиксы не являются каталогами.
Назначение префикса и разделителя поможет вам упорядочить ключи, а затем иерархически просматривать их. Для начала выберите разделитель, который не будет встречаться ни в одном имени ключей объектов, создаваемых вами. Использовать можно любой разделитель. Например, “ \ ”. Это не является уникальным разделителем, просто распространённый вариант.
Создайте имена ключей объектов по иерархическому принципу, соединив все содержащиеся уровни иерархии, обозначив каждый уровень разделителем. Например, если вы храните информацию о городах, то можете естественным образом упорядочить их по континентам, странам, провинциям. Так как в имени городов обычно нет символа «\» , то можно использовать его в качестве разделителя:
Страна1\Регион1\Город1
Страна1\Регион1\Город2
Страна2\Регион1\Город1
Чтобы перечислить в бакете только объекты корневого уровня, вы отправляете запрос GET в bucket с символом-разделителем косой черты ( / ).
Количество префиксов в бакете не ограничено. Префикс не имеет фиксированного количества символов. Это любая строка между именем бакета и именем объекта, например:
bucket/folder1/sub1/file
bucket/folder1/sub2/file
bucket/1/file
bucket/2/file
Префиксы объекта «file» будут следующими: /folder1/sub1/, /folder1/sub2/, /1/, /2/
2. Управление контролем доступом в S3 на бакет и объекты
2.1. Создание бакета
При создании бакета вы можете выбрать подходящую для вашего политику хранения (не путать с политиками доступа к бакету, о которых расскажем чуть позже). Бакет принадлежит учетной записи (USER (owner)), которая её создала. Смена владельца для уже созданного бакета невозможна. Только через создание нового бакета и перемещение данных между ними. Например, в панели управления https://cmc.objstor.cloud4y.ru:8443/ доступны политики:
Имя политики | Тип политики | Примечание |
C4Y-R3-K41-V* | Реплика фактор 3, с кворумом для чтения и записи | Эта политика гарантирует хранения трёх копий объекта на разных нодах кластера. За счёт использования кворума статус операции чтения/записи отдаются клиенту только в том случае, если не менее половины ответственных нод за хранение данных сообщат о своём успешном выполнении. С одной стороны это увеличивает длительность операции, с другой — обеспечивает максимальную надёжность хранения. Таких политик в кластере сделано несколько (V1,V2,V3 и т. д.), чтобы распределять нагрузку по базе Cassandrа и обеспечивать лучшую производительность при работе с метаданными. Мы рекомендуем использовать разные политики для хранения ваших бакетов. Особенно если в каждом бакете будет много объектов небольшого размера. |
C4Y-EC-K41 | 4 + 2 erasure coding, с кворумом для чтения и записи | Эта политика гарантирует возможность, чтения/записи объекта при недоступности одной ноды. Объект хранится с небольшим избыточным количеством. |
Выделим основные функциональные возможности, предоставляемые S3 для управления доступом к бакету:
Acess Control List (ACL)
S3 bucket policies
user-based policies
IAM policies
А также сущности пользователей:
USER (owner)
IAM USER
А теперь рассмотрим их описание и использование.
2.2. ACCESS CONTROL LIST (ACL)
Могут быть применены на как на сам bucket, так и на объект (файл) в bucket. Назначать публичный доступ на сам бакет — крайне плохая практика и её не рекомендуется использовать. Разумнее применять доступа гранулярно, на уровне объектов (файлов). Права на бакет не запрещают доступа на объект в бакет. До появления Identity and Access Management (IAM) это было основное средство контроля доступа.
В S3 есть предопределённые группы:
Authenticated users group
All users group
Log delivery group
И типы доступа:
READ (чтение)
WRITE (запись)
READ_ACP (просматривать текущие настройки разрешений для bucketа)
WRITE_ACP (изменить настройки разрешений для bucketа)
FULL_CONTROL (полный доступ)
Есть также заранее подготовленные листы доступа (canned ACL), которые могут быть назначены на bucket.
Объект единовременно может иметь только один прикреплённый к нему canned ACL. Если вы примените один canned ACL на объект, а затем примените другой canned ACL, то первый canned ACL будет удалён.
В таблице представлены доступные Canned ACL.
Canned ACL | Описание |
Private | Никому не предоставляет никаких разрешений на объект (только владелец объекта имеет разрешения на объект). Это параметр по умолчанию. |
Public Read | Разрешение на чтение (открытие или загрузку) объекта предоставляется любому пользователю, независимо от того, является ли он зарегистрированным пользователем сервиса S3. |
Authenticated Read | Разрешение на чтение списка файлов, находящихся в bucketе, предоставляется всем зарегистрированным пользователям системы. |
Bucket Owner Read | Владельцу bucket даётся разрешение на чтение. Если вы являетесь владельцем bucket и владельцем объекта, вам не нужно выбирать это разрешение, т. к. у владельца объекта уже есть полные разрешения на объект (включая разрешение на чтение). |
Bucket Owner Full Control | Владельцу бакета даются полные разрешения (разрешение на чтение объекта, чтение разрешений объекта и изменение разрешений объекта). Если вы являетесь владельцем bucket и владельцем объекта, вам не нужно выбирать это разрешение, у вас уже есть полные разрешения на этот объект. |
Дополнительные Canned ACL (HyperStore расширения для S3 API).
canned ACL | Применяются для | Разрешения |
group-read | Bucket и object | Владелец получает FULL_CONTROL. Все остальные пользователи HyperStore сервисной группы получают READ access. |
group-read-write | Bucket и object | Владелец получает FULL_CONTROL. Все остальные пользователи HyperStore сервисной группы получают READ и WRITE доступ. |
Cм. также документацию AWS по ACL.
2.3. S3 Bucket policies
Позволяют пользователям легко предоставлять доступ между учётными записями без создания ролей IAM. CMC не поддерживает создание bucket policies, их можно создать только через S3 API или стороннее клиентское приложение.
Предположим, мы хотим разрешить s3:GetObject на mybucket для учётной записи root, а также пользователю Alice. Это может быть сделано с помощью приведённой ниже политики bucketа:
{
"Version": "2012-10-17",
"Statement": [
{
"SID": "Allow",
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam:: 6161616165:user/Alice",
"arn:aws:iam:: 6161616161:root"]
},
"Action": " s3:GetObject ",
"Resource": "arn:aws:s3::: mybucket /*"
}
]
}S3 bucket policies прикрепляются только к бакетам S3. Они определяют, какие действия разрешены или запрещены для каких участников в bucketе, к которой прикреплена политика bucketа. s3 bucket policies — это тип списка управления доступом (в общем смысле, не путайте его с S3 ACL, который является отдельной функцией S3). Вы прикрепляете политики bucketа S3 на уровне bucketа, т. е. вы не можете прикрепить политику bucket-а к объекту S3, но разрешения, указанные в политике bucket-а, применяются ко всем объектам в bucketе.
Политики bucketа являются простым и мощным средством управлением контроля доступом к вашим bucketам, но очень важно понимать и определять Principal в примере выше. Если вы неправильно его определили и использовали wildcard (*), то при использовании примера ниже рискуете сделать весь ваш bucket общедоступным.
{
"Version": "2012-10-17",
"Statement": [
{
"SID": "Allow",
"Effect": "Allow",
"Principal": “*”,
"Action": " s3:GetObject ",
"Resource": "arn:aws:s3::: mybucket /*"
}
]
}
2.4. USER-BASED policies
Пользовательские политики часто используются для управления доступом в S3. Например, чтобы предоставить пользователю или роли доступ к определённым бакетам S3, можно легко определить пользовательскую политику и присоединить её к соответствующей сущности.
Например, приведённая ниже пользовательская политика позволяет любому объекту, к которому прикреплена политика, выполнять любые actions (действия) с mybucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": " s3:* ",
"Resource": ["arn:aws:s3::: mybucket ",
"arn:aws:s3::: mybucket /*"]
}
]
}2.5. IAM POLICIES
Политики IAM определяют, какие действия и на каких ресурсах разрешены или запрещены. Вы прикрепляете политики IAM к пользователям, группам или ролям IAM, которые дают определённые вами разрешения.
Пример IAM в политике ниже предоставляет сущности IAM (пользователю, группе или роли), к которой она прикреплена, разрешение на выполнение любой операции S3 над bucketом с именем mybucket, а также её содержимому.
{
"Version": "2012-10-17",
"Statement":[{
"Effect": "Allow",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::mybucket",
"arn:aws:s3:::mybucket/*"]
}
]
}Ниже приведён пример простого документа политики IAM, предоставляющего разрешение на перечисление содержимого bucket с именем mybucket:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::mybucket"
}
}Обратите внимание, что политика bucketа S3 включает элемент “Principal”, в котором перечислены участники, для которых политика bucket управляет доступом. Элемент “Principal” не нужен в политике IAM, поскольку “Principal” по умолчанию является сущностью, к которой прикреплена политика IAM. Политики bucket S3 (как следует из названия) контролируют только доступ к ресурсам S3, в то время как политики IAM могут быть применимы к другим ресурсам в облаке AWS.
2.6 Когда и какие политики применять
Используйте IAM POLICIES, если:
Вам необходимо контролировать доступ к сервисам, не только к S3. Управлять политиками IAM будет проще, поскольку вы можете централизованно управлять всеми своими разрешениями в IAM, а не распределять их между IAM и S3.
У вас есть множество bucketов в S3, которые имеют разные требования к разрешениям. Управлять политиками IAM будет проще, поскольку вам не нужно определять большое количество политик bucketа S3, а вместо этого вы можете полагаться на меньшее количество более подробных политик IAM.
Вы предпочитаете сохранять политики контроля доступа в среде IAM.
Используйте s3 bucket policies, если:
Вам нужен простой способ предоставить другому аккаунту доступ в вашей системе S3 без использования ролей, политик IAM.
Ваши политики IAM очень большие и сталкиваются с ограничением размера (до 2 Кб для пользователей, 5 КБ для групп и 10 Кб для ролей). S3 поддерживает политику bucketа размером до 20 кб.
Вы предпочитаете хранить политики контроля доступа в среде S3.
Применимость решения | Bucket | Объект | Пользователям, группам или ролям IAM |
ACL | + | + | - |
S3 bucket policies | + | - | - |
user-based policies | + | + | - |
IAM policies | - | - | + |
Ограничения по размеру политик
ТИП ПОЛИТИКИ | ДОПУСТИМЫЙ МАКСИМАЛЬНЫЙ РАЗМЕР |
IAM пользователей | 2 Кб |
IAM групп | 5 КБ |
IAM ролей | 10 Кб |
s3 bucket policies | 20 KB |
2.7 Поддерживаемые решения IAM в S3 системе от Cloudian
В нашем https://cmc.objstor.cloud4y.ru:8443/ (СMC) поддерживается создание IAM политик с помощью JSON или визуального редактора.
В CMC созданные пользователи IAM не имеют никаких разрешений до тех пор, пока вы не присоедините их к политике или группе IAM, которой применена политика. Создание пользователей IAM и групп IAM возможно не только через CMC, но и с помощью стороннего ПО, работающего по API S3. CMC поддерживает стандартные политики IAM Amazon Web Services и большинство элементов политики для предоставления разрешений служб S3 или IAM.
Поддержка IAM не является 100%, но поддерживает большинство элементов политик, действий, ресурсов и/или ключей условий, указанных в документации AWS для формирования политики IAM.
IAM actions (действия) чувствительны к регистру.
Инструкции по созданию политик IAM для разрешений служб S3 или IAM также см. в документации AWS
2.8 Идеология политик и их применение
Теперь, когда мы рассмотрели основные способы управления доступом к ресурсам S3, давайте посмотрим, как принимаются решения по управлению доступом. Всякий раз, когда приходит запрос в S3, решение об авторизации зависит от объединения всех применимых политик: ACL, S3 bucket policies, user-based policies.
По умолчанию все ресурсы S3 являются приватными. Только владелец ресурса (учетная запись, которая его создала), может получить доступ к ресурсу. Владелец ресурса может дополнительно предоставить разрешения на доступ другим пользователям, написав политику доступа.
Фактически система исходит из идеологии наименьших привилегий. Доступ предоставляется только в том случае, если не существует явного отрицания и есть явное разрешение. Проще говоря, если у вас нет никаких разрешений, вам не будет предоставлен доступ. А явное отрицание всегда превосходит явное разрешение.
2.9 Пример предоставления полного доступа к своим бакетам IAM пользователю с доступом только с определенного IP, используя IAM Policies
При получении доступа в объектное хранилище S3 от компании Cloud4Y вы получаете имя своей группы (demo-grp-1), а также администратора группы (demo-user-1). Из-под админской учётки вы можете создавать дополнительных пользователей (USER (owner)) в своей группе.
Входим в https://cmc.objstor.cloud4y.ru:8443/
И от нашего пользователя создадим:
два бакета: demo-s3-bucket-1, demo-s3-bucket-2, с политикой хранения C4Y-R3-K41-V3
и
два пользователя iam: demo-iam-user1, demo-iam-user2, и создадим им данные для доступа Access Key ID and Secret Key ID
Через Create new key создаём Access Key ID and Secret Key ID (внимание, его нужно обязательно запомнить, т. к. получить его можно только при создании ключевой пары).
и
Для созданного пользователя IAM мы можем назначить несколько пар Access Key ID and Secret Key ID.
политику demo-iam-policy-1 для пользователя demo-iam-user1 с доступом к бакетам demo-s3-bucket-1, demo-s3-bucket-2 и ограничением доступа по IP с 176.53.ХХХ.ХХХ
jSON
и
Через кнопку "Attach to user" добавим нашего пользователя demo-iam-user1.
Теперь проверим полученные результаты, используя клиента, поддерживающего S3 протокол (например S3 Browser), и выполним запрос с нашего сервера 176.53.ХХХ.ХХХ. Но сначала настроим подключение:
Авторизуемся под пользователем demo-iam-user1 и получаем доступ к бакетам, описанным в политике.
Авторизуемся под пользователем demo-iam-user2. Поскольку мы не назначили политики, то и доступ не получаем.
Если мы повторим описанные выше действия с другого сервера, не описанного в политике, то мы не получим доступ. Тем самым мы ограничили доступ к бакетам только с разрешённых адресов, а также обеспечили необходимым IAM пользователям доступ к указанным бакетам.
2.10 Пример предоставления доступа к своему бакету другому пользователю с правом чтения только с указанного IP адреса используя S3 Bucket Policies
В нашей группе demo-cmc-grp-1, в дополнение к существующему demo-cmc-user-1 создадим еще одного пользователя: demo-cmc-user-2.
У пользователя demo-cmc-user-1, уже есть бакет demo-s3-bucket-1 (созданный ранее), а для пользователя demo-cmc-user-2 создадим бакет demo-s3-bucket-3.
Установим CLI и настроим два профиля для пользователя demo-cmc-user-1 и demo-cmc-user-2. И посмотрим список бакетов при помощи команд:
aws s3api --endpoint-url https://s3.objstor.cloud4y.ru:443/ --profile demo-cmc-user-1 list-buckets
aws s3api --endpoint-url https://s3.objstor.cloud4y.ru:443/ --profile demo-cmc-user-2 list-buckets
Запомним ID наших пользователей и какие бакеты у них есть:
demo-cmc-user-1, ea25fa386cf9a26db2fd8c9650de065d
demo-cmc-user-2, 86357359a3e5deb3daf86d0ead918d08
Теперь давайте дадим доступ пользователю demo-cmc-user-1 только на чтение и просмотр содержимого бакета созданного пользователем demo-cmc-user-2 и разрешим доступ только с IP адреса: 176.53.ХХХ.ХХХ. Т. к. править Bucket Policies в CMC нельзя, то будем использовать все тот же S3 Browser, использующий S3 API. Подключимся под demo-cmc-user-2 и для бакета demo-s3-bucket-3, назначим политику:
Теперь подключимся пользователем demo-cmc-user-1, используя S3 Browser и подключим внешний бакет:
За счет назначенных Action (действий) мы смогли получить доступ к бакету, просмотреть его содержимое и скачивать объекты.
Подобным способом мы можем назначить и другие действия на бакет.
Однако будьте внимательны с политиками и вначале проведите проверки на тестовых бакетах и работы вашего ПО, а потом на продуктовых. Особенно аккуратно применяйте политики к уже созданным бакетам с множеством объектов.
Давайте представим, что мы дали другому пользователю доступ к бакету не только на чтение, но и на запись. При такой схеме при загрузке объектов во внешний бакет владельцем бакета будет один пользователь, который его создал. А вот владельцем объекта внутри уже другой — тот, который его закачал.
Для первичной подготовки шаблона политики, удобно использовать AWS Policy Generator, а потом подправить полученный результат под свои требования.
Вот такие дела. Спасибо за внимание!
Что ещё интересного есть в блоге Cloud4Y
→ Как открыть сейф с помощью ручки
→ Сделайте Linux похожим на Windows 95
→ Как распечатать цветной механический телевизор на 3D-принтере
→ WD-40: средство, которое может почти всё
→ Взлёт и падение игрового чипа 6502
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и ВКонтакте.
