3.Хранение и управление доступом на данные в объектном хранилище S3

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 доступен только по 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/ доступны политики:

 

Имя политики  Тип политики Примечание 
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) это было основное средство контроля доступа.

Рисунок 1.


Рисунок 1.

В S3 есть предопределённые группы:

  • Authenticated users group
  • All users group
  • Log delivery group

И типы доступа:

  • READ (чтение)
  • WRITE (запись)
  • READ_ACP (просматривать текущие настройки разрешений для bucketа)
  • WRITE_ACP (изменить настройки разрешений для bucketа)
  • FULL_CONTROL (полный доступ)

Есть также заранее подготовленные листы доступа (canned ACL), которые могут быть назначены на bucket.

Рисунок 2.

Объект единовременно может иметь только один прикреплённый к нему 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 или стороннее клиентское приложение.

Рисунок 1.

Предположим, мы хотим разрешить 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, которые дают определённые вами разрешения. 

 

Рисунок 1.

Пример 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 Когда и какие политики применять

Рисунок 1.

Используйте IAM POLICIES, если:

  • Вам необходимо контролировать доступ к сервисам, не только к S3. Управлять политиками IAM будет проще, поскольку вы можете централизованно управлять всеми своими разрешениями в IAM, а не распределять их между IAM и S3.
  • У вас есть множество  bucketов в S3, которые имеют разные требования к разрешениям. Управлять политиками IAM будет проще, поскольку вам не нужно определять большое количество политик bucketа S3, а вместо этого вы можете полагаться на меньшее количество более подробных политик IAM.
  • Вы предпочитаете сохранять политики контроля доступа в среде IAM.

 

Рисунок 1.

 

Используйте 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.cloud4u.com:8443/ (СMC) поддерживается создание IAM политик с помощью JSON или визуального редактора.  

Рисунок 21. 

В 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. 


Рисунок 3.

По умолчанию все ресурсы S3 являются приватными. Только владелец ресурса (учетная запись, которая его создала), может получить доступ к ресурсу. Владелец ресурса может дополнительно предоставить разрешения на доступ другим пользователям, написав политику доступа. 

Фактически система исходит из идеологии наименьших привилегий. Доступ предоставляется только в том случае, если не существует явного отрицания и есть явное разрешение. Проще говоря, если у вас нет никаких разрешений, вам не будет предоставлен доступ. А явное отрицание всегда превосходит явное разрешение.


2.9 Пример предоставления полного доступа к своим бакетам IAM пользователю с доступом только с определенного IP используя IAM Policies 

При получении доступа в объектное хранилище S3 от компании Cloud4Y вы получаете имя своей группы (demo-grp-1), а также администратора группы (demo-user-1). Из-под админской учётки вы можете создавать дополнительных пользователей (USER (owner)) в своей группе.


Входим в https://cmc.objstor.cloud4u.com:8443/ 


Рисунок 10.

И от нашего пользователя создадим:  

  • два бакета:  demo-s3-bucket-1, demo-s3-bucket-2, с политикой хранения C4Y-R3-K41-V3


Рисунок 11.

 


Рисунок 12.


Рисунок 13.

 

 

  • два пользователя iam: demo-iam-user1, demo-iam-user2, и создадим им данные для доступа Access Key ID and Secret Key ID


Рисунок 14.

 

Через Create new key создаём Access Key ID and Secret Key ID (внимание, его нужно обязательно запомнить, т. к. получить его можно только при создании ключевой пары).
 
Рисунок 15.

 


Рисунок 16.

 

Для созданного пользователя IAM мы можем назначить несколько пар Access Key ID and Secret Key ID 

Рисунок 23.


Рисунок 17.

 

  • политику demo-iam-policy-1 для пользователя demo-iam-user1 с доступом к бакетам demo-s3-bucket-1, demo-s3-bucket-2 и ограничением доступа по IP с 176.53.ХХХ.ХХХ   


Рисунок 18.


jSON


Рисунок 19.

 

Рисунок 24.

 

Через кнопку "Attach to user" добавим нашего пользователя demo-iam-user1.


Рисунок 22.

 

 

Теперь проверим полученные результаты, используя клиента, поддерживающего S3 протокол (например S3 Browser), и выполним запрос с нашего сервера 176.53.ХХХ.ХХХ. Но сначала настроим подключение:


Рисунок 25.


Рисунок 26.

Авторизуемся под пользователем demo-iam-user1 и получаем доступ к бакетам, описанным в политике.
 
Рисунок 27.

Авторизуемся под пользователем demo-iam-user2. Поскольку мы не назначили политики, то и доступ не получаем. 


Рисунок 28.

 

Если мы повторим описанные выше действия с другого сервера, не описанного в политике, то мы не получим доступ. Тем самым мы ограничили доступ к бакетам только с разрешённых адресов, а также обеспечили необходимым 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


Рисунок 29.

  • aws s3api --endpoint-url https://s3.objstor.cloud4u.com:443/ --profile demo-cmc-user-2 list-buckets


Рисунок 30.


Запомним 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, назначим политику:


Рисунок 31.


Рисунок 32.

   
Теперь подключимся пользователем demo-cmc-user-1 используя S3 Browser и подключим внешний бакет:


Рисунок 33.


Рисунок 34.

За счет назначенных Action (действий) мы смогли получить доступ к бакету, просмотреть его содержимое и скачивать объекты. 

Рисунок 35.


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

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

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

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


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


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

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

  • 47 Пользователи нашли это полезным
Помог ли вам данный ответ?

Связанные статьи

5.Работа с S3 средствами AWS SDK Client на php

0. Устанавливаем php Инструкция здесь 1. Установим composer Переходим в директорию из...

1.Как начать работу с объектным хранилищем

ОБЪЕКТНОЕ ХРАНИЛИЩЕ ОТ CLOUD4Y Наше объектное хранилище построено на платформе компании Cloudian...

2.Как начать работу с S3 Cloud4y используя AWS Command Line Interface (CLI)

1) Устанавливем AWS CLI - На Windows, загружаем  AWSCLI-64  или  AWSCLI-32 разрядный установщик...

7. Биллинг в системе объектного хранилища S3

  Биллинг в S3 учитывает в себе следующие параметры: Занимаемое место Количество GET/HEAD...

4.Способы работы с объектным хранилищем через различное программное обеспечение

Подготовка идентификационных данных 1. Авторизуйтесь в объектном хранилище Cloud4Y:...