Preguntes Freqüents - FAQ

1.Организация хранения данных в объектном хранилище 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.cloud4u.com/<bucket>?<parameters> 
• http://<bucket>.s3.objstor.cloud4u.com?<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.cloud4u.com:8443/ доступны политики:

Выделим основные функциональные возможности, предоставляемые 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 (HyperStore расширения для S3 API)

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.   

Ограничения по размеру политик 

2.7 Поддерживаемые решения IAM в S3 системе от Cloudian  

В https://cmc.objstor.cloud4u.com: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:

• Policies and Permissions
• IAM JSON Policy Elements Reference
• Actions, Resources, and Condition Keys for Amazon S3
• Actions, Resources, and Condition Keys for Identity And Access Management

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.cloud4u.com: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.cloud4u.com:443/ --profile demo-cmc-user-1 list-buckets

• aws s3api --endpoint-url https://s3.objstor.cloud4u.com: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 (действий) мы смогли получить доступ к бакету, просмотреть его содержимое и скачивать объекты. 

Подобным способом мы можем назначить и другие действия на бакет.

2.10 Пример предоставления доступа к своему бакету другому пользователю через CMC

У нас есть группа test, в ней у нас есть пользователи и давайте дадим пользователю test-access, доступ на бакет у пользователя test.

Для этого в CMC, в свойствах бакета, через ADD NEW добавим ИМЯ_ГРУППЫ|ИМЯ_ПОЛЬЗОВАТЕЛЯ и выдадим необходимые права.

Далее, точно так же, у пользователя test-access через подключение внешнего бакета, получим доступ к бакету test

Однако, будьте внимательны с политиками и вначале проведите проверки на тестовых бакетах и работы вашего ПО, а потом на продуктовых. Особенно аккуратнее применяйте к уже созданным бакетам с множеством объектов. 

Давайте представим, что мы дали другому пользователю доступ к бакету не только на чтение, но и на запись. При такой схеме, при загрузке объектов во внешний бакет, владельцем бакета будет один пользователь, который его создал. А вот владельцем объекта внутри уже другой - тот, который его закачал.

Для первичной подготовки шаблона политики, удобно использовать  AWS Policy Generator  ну и потом подправить полученный результат, под свои требования. 


По работе с S3 используя другое программное обеспечение, рекомендуем ознакомиться с статьей.

Ещё не пробовали услугу "Облачный хостинг" от Cloud4Y?

Отправьте заявку сейчас и получите 14-ти дневный бесплатный доступ.