Как автоматизировать оркестровку прав доступа в корзинах AWS S3

Несколько лет назад, когда локальные Unix-серверы с большими файловыми системами были популярны, компании разрабатывали обширные правила и стратегии управления папками для администрирования прав доступа к разным папкам для разных людей.

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

Другие типичные примеры могут включать:

• разделение данных между средами разработки, тестирования и производства
• продающий контент, недоступный широкой аудитории
• законодательный контент для конкретной страны, который нельзя просмотреть или получить к нему доступ из другого региона
• контент, связанный с проектом, где «данные руководства» должны предоставляться только ограниченному кругу лиц и т. д.

Существует потенциально бесконечный список таких примеров. Дело в том, что всегда есть необходимость организовать права доступа к файлам и данным между всеми пользователями, которым платформа предоставляет доступ.

В случае с локальными решениями это была рутинная задача. Администратор файловой системы просто установил некоторые правила, использовал выбранный инструмент, а затем люди были сопоставлены с группами пользователей, а группы пользователей были сопоставлены со списком папок или точек монтирования, к которым они должны иметь доступ. Попутно уровень доступа был определен как доступ только для чтения или доступ для чтения и записи.

Теперь, глядя на облачные платформы AWS, очевидно, что у людей будут аналогичные требования к ограничениям доступа к контенту. Решение этой проблемы должно быть, однако, теперь другим. Файлы больше не сопротивляются на серверах Unix, а находятся в облаке (и потенциально доступны не только для всей организации, но даже для всего мира), а контент хранится не в папках, а в корзинах S3.

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

Простой, но в значительной степени ручной подход

Один из способов решения этой проблемы без какой-либо автоматизации относительно прост:

• Создайте новое ведро для каждой отдельной группы людей.
• Назначьте права доступа к корзине, чтобы только эта конкретная группа могла получить доступ к корзине S3.

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

По умолчанию под одной учетной записью AWS можно создать не более 100 корзин S3. Это ограничение можно увеличить до 1000, указав увеличение лимита обслуживания в билете AWS. Если эти ограничения не вызывают беспокойства в вашем конкретном случае реализации, вы можете позволить каждому из ваших отдельных пользователей домена работать с отдельной корзиной S3 и положить этому конец.

Проблемы могут возникнуть, если есть группы людей с межфункциональными обязанностями или просто люди, которым нужен доступ к содержимому большего количества доменов одновременно. Например:

• Аналитики данных, оценивающие содержание данных для нескольких различных областей, регионов и т. д.
• Группа тестирования использовала общие сервисы, обслуживающие разные команды разработчиков.
• Отчеты о пользователях, которым требуется построить анализ панели мониторинга по разным странам в одном регионе.

Как вы можете себе представить, этот список снова может расти настолько, насколько вы можете себе представить, а потребности организаций могут генерировать всевозможные варианты использования.

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

Итак, как же добиться того же более организованным и автоматизированным способом?

Введите теги для ведер

Если подход «сегмент для каждого домена» не работает, любое другое решение приведет к использованию общих сегментов для большего количества групп пользователей. В таких случаях необходимо выстроить целую логику назначения прав доступа в какой-то области, которую легко изменить или динамически обновить.

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

Если вся логика построена на основе тегов корзины, а все остальное зависит от конфигурации, зависящей от значений тегов, динамическое свойство гарантировано, поскольку можно переопределить цель корзины, просто обновив значения тегов.

Какие теги использовать, чтобы это работало?

Это зависит от вашего конкретного варианта использования. Например:

• Может потребоваться разделить сегменты по типам среды. Таким образом, в этом случае одно из имен тегов должно быть что-то вроде «ENV» с возможными значениями «DEV», «TEST», «PROD» и т. д.
• Может быть, вы хотите разделить команду по стране. В этом случае другим тегом будет «COUNTRY» со значением названия страны.
• Или вы можете разделить пользователей на основе функционального отдела, к которому они принадлежат, например, бизнес-аналитиков, пользователей хранилища данных, специалистов по данным и т. д. Таким образом, вы создаете тег с именем «USER_TYPE» и соответствующим значением.
• Другим вариантом может быть то, что вы хотите явно определить фиксированную структуру папок для определенных групп пользователей, которую они должны использовать (чтобы не создавать свой собственный беспорядок папок и не теряться там с течением времени). Вы можете сделать это снова с помощью тегов, где вы можете указать несколько рабочих каталогов, таких как: «данные/импорт», «данные/обработано», «данные/ошибка» и т. д.

В идеале вы хотите определить теги так, чтобы их можно было логически комбинировать и формировать целую структуру папок в корзине.

Например, вы можете комбинировать следующие теги из приведенных выше примеров, чтобы создать специальную структуру папок для разных типов пользователей из разных стран с предопределенными папками импорта, которые они должны использовать:

• /<ENV>/<USER_TYPE>/<СТРАНА>/<ЗАГРУЗИТЬ>

Просто изменив значение <ENV>, вы можете переопределить назначение тега (назначать ли его экосистеме тестовой среды, dev, prod и т. д.).

Это позволит использовать одно и то же ведро для многих разных пользователей. Сегменты не поддерживают папки явно, но они поддерживают «метки». В конце концов, эти метки работают как подпапки, потому что пользователям нужно пройти через ряд меток, чтобы получить доступ к своим данным (точно так же, как они делали бы это с подпапками).

Создавайте динамические политики и сопоставляйте теги сегментов внутри

Определив теги в какой-либо пригодной для использования форме, следующим шагом будет создание политик корзины S3, которые будут использовать теги.

Если политики используют имена тегов, вы создаете нечто, называемое «динамическими политиками». В основном это означает, что ваша политика будет вести себя по-разному для сегментов с разными значениями тегов, на которые политика ссылается в форме или заполнителях.

Этот шаг, очевидно, включает в себя некоторое пользовательское кодирование динамических политик, но вы можете упростить этот шаг, используя инструмент редактора политик Amazon AWS, который поможет вам в этом процессе.

В самой политике вы захотите закодировать конкретные права доступа, которые будут применяться к корзине, и уровень доступа таких прав (чтение, запись). Логика будет считывать теги в корзинах и создавать структуру папок в корзинах (создавая метки на основе тегов). На основании конкретных значений тегов будут созданы подпапки, а по ходу будут назначены необходимые права доступа.

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

Это действительно эффективный способ управления назначением прав доступа организованным, централизованным способом для большого количества сегментов, когда ожидается, что каждый сегмент будет следовать некоторым заранее согласованным шаблонным структурам и будет использоваться вашими пользователями в течение вся организация.

Автоматизируйте регистрацию новых сущностей

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

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

Последний шаг — максимально упростить адаптацию новых пользователей, новых сегментов и даже новых тегов. Это привело к еще одному пользовательскому коду, который, однако, не должен быть слишком сложным, при условии, что ваш процесс адаптации имеет несколько очень четких правил, которые можно инкапсулировать с помощью простой, прямой логики алгоритма (по крайней мере, таким образом вы можете доказать, что ваш процесс имеет некоторую логику и не слишком хаотичен).

Это может быть так же просто, как создание исполняемого скрипта с помощью команды AWS CLI с параметрами, необходимыми для успешной интеграции нового объекта в платформу. Это может быть даже серия CLI-скриптов, выполняемых в определенном порядке, например:

• create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
• create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
• update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
• create_user_group(<user_type>,<country>,<env>)
• и т.п.

Вы поняли.

Профессиональный совет

Если хотите, есть один профессиональный совет, который можно легко применить поверх вышеперечисленного.

Динамические политики можно использовать не только для назначения прав доступа к расположениям папок, но и для автоматического назначения прав обслуживания для корзин и групп пользователей!

Все, что потребуется, — это расширить список тегов в корзинах, а затем добавить права доступа к динамической политике для использования определенных сервисов для конкретных групп пользователей.

Например, может существовать группа пользователей, которым также требуется доступ к определенному серверу кластера баз данных. Это, несомненно, может быть достигнуто с помощью динамических политик, использующих задачи корзины, особенно если доступ к службам управляется ролевым подходом. Просто добавьте в код динамической политики часть, которая будет обрабатывать теги, относящиеся к спецификации кластера базы данных, и назначьте привилегии доступа к политике непосредственно этому конкретному кластеру БД и группе пользователей.

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

Вы также можете ознакомиться с этими командами AWS S3 для управления сегментами и данными.