Хранение и управление доступом на данные в хранилище S3

Привет! Сегодня хотим рассказать о, как использовать бакеты, хранить данные, настраивать политики и управлять доступом на данные при работе c объектным хранилищем S3.

dfd27611d5cce51225921f2153c9a863.jpg

S3 — это не иерархическая файловая система, а всего лишь хранилище ключей и значений, хотя ключ часто используется как путь к файлу для организации данных. Чтобы разместить файл в объектном хранилище S3, его необходимо поместить в бакет. Бакет (bucket — ведро) — это сущность для организации хранения в хранилище.

1.1 К имени бакета применяются следующие требования:

  • длина имени от 3 до 63 символов;

  • может содержать только латинские символы;

  • может состоять только из строчных букв, цифр, точек (.) и дефисов (-);

  • должно начинаться и заканчиваться только буквой или цифрой;

  • не должно содержать две смежные точки;

  • не не должно быть в формате IP-адреса;

  • не должно начинаться с префикса  xn--;

  • не должно заканчиваться на -s3alias.

Точки и дефисы допускаются, но не во всех случаях. При некоторых дополнительных функциях это может вызывать проблемы совместимости. Мы рекомендуем избегать использования точек (.)

Примеры имён бакета:  

Допустимы и соответствуют требованиям:

  • my-bucket-name

  • mybucket1

  • my-bucket-name-2022

Допустимы, но не рекомендуются для использования: Недопустимы:

  • 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.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) это было основное средство контроля доступа.

ff24102568a00403d911c39e15b18e09.png7b248315f91982ca982427490c8bf1d2.png

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

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

  • READ (чтение)

  • WRITE (запись)

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

  • WRITE_ACP (изменить настройки разрешений для bucketа)

  • FULL_CONTROL (полный доступ)

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

50bd8e94a00a067ebc9b5f89c39ddc76.png

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

a3167e46a9c4f6630b49febe5fbad952.png

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

c617b30e012b13624c415d676b9b9354.png

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

7a76cc64400eeb28c2d15c554bbf332a.png

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

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

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

  • Вы предпочитаете сохранять политики контроля доступа в среде IAM.

3cd89a7094050314786170054d572ad0.png

Используйте 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 или визуального редактора.  

8eea89e66bf878632ea5c65ba4285c8d.png

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

233ffc7d2a0b22e583992e57ce30ef06.png

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

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

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

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

Входим в https://cmc.objstor.cloud4y.ru:8443/ 

d25ebd5ea7f43c3e35e514c2fe239e4b.png

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

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

e77d391e300df3ddd35c5be3ac2abe2f.png

и

eb4dc08d78c6d0ff2f55c3bc2463b8b7.png9c9da0476d574ba8b4ea0ed19a85e79a.png

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

c38259e3c018c9208615620323efb7a3.png

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

8e06af2f51c50cd38cff99b7e396f41b.png

и

fbd49e6e8ca46ed32784504c6f70f0fd.png

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

f78ed13b66abb9b47d5c03e18876b622.pngf7fb41ca4a2d709f822fbb4d8b8d31a3.png

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

e2cfa5fe5a090f73d6a22d08ab583d8a.png

jSON

eaeb1dcc100523b559213fec79eb9537.png

 и

be3d52f25970ad3b82645d98f57e6d78.png

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

388ab62db36f8e430e71500b0e289629.png

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

57cf4bd28c457b2fb5473a04aab46604.png13c47bdda816ea6536113c3ea1b71750.png

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

361667f80fd85b35e17c48f49e7fc82e.png

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

a14eefb3e8fb11bf954cf47b29c7e56f.png

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

287d7e9cf0fc0cf189763d4c7daf1d4f.png

aws s3api --endpoint-url https://s3.objstor.cloud4y.ru:443/ --profile demo-cmc-user-2 list-buckets

1befa9684972ec6a5e5af52ff9b747c6.png

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

1664f627d5cd341729b5e94fa7cdfbcb.pnga05c358dd44818f664cb8c56e050f019.png

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

298e9103e8afdf48e8f54f129efdea17.png684c9e879b638c32e18b2565164b6e67.png

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

84d445878fe36f0de56aa6c33326a0e0.png


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

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

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

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

Вот такие дела. Спасибо за внимание!

Что ещё интересного есть в блоге Cloud4Y

→ Как открыть сейф с помощью ручки

→ Сделайте Linux похожим на Windows 95

→ Как распечатать цветной механический телевизор на 3D-принтере

→ WD-40: средство, которое может почти всё

→ Взлёт и падение игрового чипа 6502

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и ВКонтакте.

Свежая серия

© Habrahabr.ru