Изобретаем IAM для облака MWS: знакомство и ресурсная модель
Мы с ребятами решили сделать облако. Не такое облако, которое «переносите свои файлы в облако», и даже не такое, которое «разверните сайт у нас на CMS, домен — в подарок». А то, что приходит в голову при использовании слова «гиперскейлер».
Я, Андрей Халиуллин, отвечаю за разработку сервиса IAM (Identity and Access Management) новой облачной платформы MWS. Поскольку мы хотим вести по возможности открытый диалог с рынком и комьюнити, в какой-то момент я получил задачу перестать писать IAM и начать писать статью про то, как мы пишем IAM. Мне есть что рассказать про исследование рынка облачных провайдеров, reverse engineering продуктовых и технологических решений, про технические вызовы в части надёжности, масштабируемости и обуздания продуктовой сложности сервисов и даже про попытки осознать «А что такое IAM?».
После нескольких подходов к этой статье мне удалось немного пройтись по поверхности темы управления ресурсами в облаке — и так статья превратилась в идею цикла статей о разработке IAM.
Конкретно в этом тексте я сделаю некоторую подводку о том, зачем нужен IAM, и затем расскажу об уровнях ресурсной модели абстрактного облачного провайдера с комментариями, зачем каждый уровень нужен и что мы про это думаем в MWS. А дальше — следите за нашим хабом.
Зачем нужен IAM в сервисах
Разграничение доступа — неотъемлемая часть любого современного сервиса, будь то социальная сеть или облачная платформа. Модель управления доступом сервиса определяет то, каким субъектам (пользователям, сотрудникам, роботам) разрешён доступ к каким ресурсам (деньгам на банковском счёте, постам в соцсети или виртуальным машинам в облаке) и как этими доступами можно управлять.
B2C-сервисы, как правило, реализуют относительно простую и прямолинейную модель управления доступом: кто ресурс создал — тот им и управляет. Система должна быть простая, чтобы каждый из миллионов клиентов мог использовать сервис без необходимости прочитать 500-страничную документацию по управлению доступом. И B2C-сервисы, как правило, могут себе позволить простую систему исходя из своих сценариев. Кто может редактировать пост в соцсети? Очевидно тот же, кто его создал, — владелец поста. Модель «владения» ресурсами фактически — цифровое отражение привычной модели взаимодействия человека с ресурсами реального мира: я как владелец машины могу на ней ездить, могу не ездить. Могу продать, одолжить другу или разобрать на запчасти и сделать из покрышек лебедей для огорода.
B2B-сервисы, в свою очередь, отличаются более вычурной моделью управления доступом. Клиентом B2B-сервиса выступает компания, сотрудники который должны иметь разные наборы полномочий по отношению к различным ресурсам компании. Более того, модель управления на основе владения слабо подходит для качественного управления процессами и безопасностью в организации. Было бы несколько удивительно, если бы строитель мог вынуть кирпич из построенного здания просто потому, что «я его туда положил — значит, я же могу его забрать». Ресурсами организации и правилами доступа к ним владеет сама организация.
Правда «организация» не заходит в интерфейс облака и не раздаёт доступы. В B2B-сервисах, включая облачные платформы, сотрудники компаний получают права в соответствии со своими рабочими функциями — от управления виртуалками до управления правами других пользователей. Чтобы стало ещё интереснее — штат настоящей организации, прямо как корабль Тесея, может быть заменён «по досочке» на совершенно новый набор сотрудников, выполняющих работу в B2B-сервисе, и это не должно повлиять на работу сервиса, который будет продолжать «подчиняться указаниям» сотрудников организации, наделённых определёнными ролями.
«Большая тройка» сущностей
Любая система управления доступом, как ни странно, управляет доступом. На базовом уровне это означает, что ключевая задача IAM в облаке — при совершении любого действия в системе (для простоты — при любом вызове API) — ответить на вопрос, разрешено ли это действие. Чтобы унифицировать процесс управления доступом, необходимо как-то формализовать и вывести общую модель этого процесса принятия решения.
Большинство моделей сводится к тому, что любое действие в системе раскладывается на три компонента:
Ресурс: над чем совершается действие.
Субъект: кто запросил выполнение действия.
Тип действия:, а что, собственно, происходит.
Таким образом, принятие решения о разрешении какого-либо действия сводится к вопросу «можно ли субъекту X совершать действие Y над ресурсом Z?», а IAM становится «системой управления связью трёх вертикалей» — звучит несложно. Давайте посмотрим на детали и обсудим работу с ресурсами в облаке.
Ресурсная модель
Что такое ресурсная модель? Облачные ресурсы должны «где-то жить». Я говорю не про физическую аллокацию железяк, а про логическую принадлежность ресурсов. Как мы уже выяснили, клиентом B2B-сервиса выступает организация, и клиенту бы хотелось иметь свои ресурсы в каком-то одном месте. Этим «одним местом» не может быть человеческий аккаунт некого «супер-админа-владельца-основателя», потому что, как мы понимаем, живые люди — существа довольно непостоянные относительно того, где они работают сегодня, завтра и послезавтра.
В любом облаке ресурсы клиентов живут в неких абстрактных контейнерах. Дальше сходства облаков заканчиваются и начинаются различия.
Контейнеры для вычислительных ресурсов у разных облачных провайдеров
Первое, что бросается в глаза, — разные названия. Но это не самая увлекательная часть, гораздо интереснее тонкая семантическая разница, которая подсвечена цветом.
На картинке представлен своеобразный «взгляд снизу»: это контейнеры, в которых находятся вычислительные ресурсы у разных облачных провайдеров. С этими контейнерами devops-инженеры взаимодействуют бОльшую часть времени. Но Resource Group в Azure — это не прямой аналог Project в GCP, несмотря на то, что они — «листовые контейнеры» в ресурсных моделях своих облаков. Всё дело в том, что на Resource Group нельзя привязать отдельный биллинг-аккаунт или управлять квотами, а на GCP Project — можно.
Если чуть достроить картинку вверх — можно увидеть, что у Azure всё-таки есть аналог проекта, он называется Subscription. Это не листовой контейнер — в нём облачные ресурсы не заводятся.
Тенанты облачных провайдеров
Для того чтобы устранить путаницу в терминологии, давайте введём абстрактный термин для обозначения слоя ресурсной модели, на котором контролируются квоты и управляется биллинг, — назовём его «тенант».
Почему эта разница в семантике слоёв иерархии ресурсов так важна? Контейнеры, или уровни ресурсной иерархии, помимо задачи группировки похожих ресурсов для удобства, решают ряд других задач как для облачного провайдера, так и для его клиентов. И большинство этих задач сводится к разным видам изоляции.
Давайте представим, что у меня есть большой IT-бизнес с десятком отдельных продуктовых команд. Каждая команда разрабатывает свой продукт, каждый продукт должен существовать хотя бы в двух окружениях: production и testing. Как мне приземлить свой бизнес на ресурсную модель провайдера с ресурсными группами?
На первый взгляд — ну давайте выдадим каждой продуктовой команде по тенанту, а они внутри себя разберутся — нарежут свои тенанты на ресурсные группы для прода, тестинга и других окружений. Выглядит довольно неплохо, каждый продукт запрашивает у поддержки облака нужные ему квоты, при этом при желании можно даже назначить на разные продуктовые команды разные биллинг-аккаунты, чтобы оплачивать инфраструктуру продуктов независимо.
Окружения продукта живут в разных ресурсных группах тенанта
Проблемы начинаются, когда разработчики в рамках исследовательской деятельности нальют в dev-бакет пару-тройку сотен ТБ тестовых данных, съев квоту на объём Object Storage продукта во всех окружениях сразу. Или когда тимлид в своём dev-окружении запустит кубер на все деньги и забудет его выключить, потратив общий бюджет продукта на инфраструктуру. Исход обоих сценариев — отказ продуктов клиента в продакшне.
Корень проблемы в том, что ресурсная группа как концепция — не может предоставить полноценной изоляции ресурсов. На рынке облачных провайдеров сейчас не существует консенсуса на тему того, насколько ресурсные группы полезны или вредны. С одной стороны, это просто дополнительная функциональность, которую клиент может использовать, а может игнорировать. С другой стороны, само наличие такой абстракции зачастую подталкивает клиентов к использованию антипаттернов при проектировании ресурсной модели своей организации.
Мы в MWS приняли решение не вводить ресурсные группы в своём облаке. Тем более что по облакам понемногу распространяется другой тренд — теги.
Теги — предмет для целой статьи, и, я надеюсь, когда-нибудь мы её напишем, но если коротко — поддержка структурированных тегов с имплементацией контроля доступа во всех ресурсах облака позволяет не только решить те же задачи, которые решают ресурсные группы (группировка для упрощения навигации, разграничение доступов, детализация расходов бюджета и многое другое), но также позволяет решить это «в нескольких измерениях».
Кроме того, теги, благодаря своей необязательности, могут быть добавлены в модель управления ресурсами облака в любой момент, в отличие от ресурсных групп. Да, некоторые облачные провайдеры в процессе своего развития вносили изменения в свои ресурсные модели, но изменение типа листового контейнера в облаке — это нетривиальное изменение контракта между IAM и десятками сервисов облака, игра не стоит свеч.
Организации
Запрыгнем сразу вверх ресурсной иерархии. Коридорные опросы показывают, что заметная часть разработчиков с трудом понимают смысл наличия «организации» в облаке, остальные — не подозревают о существовании «организаций» вообще.
Почти любой разработчик, который «с улицы» регистрируется в облаке, первые несколько минут своего знакомства с сервисом продирается через дебри ненужной информации и интерфейсов, чтобы наконец получить первый ощутимый ресурс — развёрнутую виртуалку. Когда он наконец-то заполучил виртуалку, начинает изучать ландшафт. К этому моменту он уже согласился с EULA, отдал куда-то данные своей банковской карты и, не задумываясь, согласился создать всю вертикаль ресурсной модели «как-нибудь», чтобы получить на руки тот самый контейнер, в который крепятся ресурсы в этом конкретном облаке.
Правда в том, что в процессе изучения облака, развёртывания pet-проектов и даже администрирования реального коммерческого проекта редкий разработчик испытывает потребность заглянуть в ресурсную иерархию повыше тенанта и посмотреть, что там происходит.
Но как мы обсудили выше, тенант — единица изоляции. Если компания разрабатывает несколько продуктов или даже если компании нужна тестовая среда для своего продукта (у вас же есть тестовая среда, правда?) — компания вынуждена иметь несколько тенантов в облаке. Тем не менее, должен быть какой-то способ эти контейнеры объединить. Наверняка компания захочет переиспользовать платёжные аккаунты между какими-то проектами, пошарить доступ между сотрудниками. В некоторых случаях настроить кросс-тенантные стыки, как-то централизованно управлять настройками безопасности, да и просто видеть все свои тенанты в одном месте, в конце концов. Именно эти задачи решает уровень «организации». К названию этого слоя иерархии провайдеры подходят относительно согласованно.
Уровень «Организации» в иерархии облаков «Большой тройки»
В идеальной вселенной одна организация реального мира приходится на одну «организацию» облачного провайдера.
Помимо того что «организация» содержит в себе тенанты с конечными ресурсами — типа виртуалок и прочих сущностей, из которых клиент строит свою вычислительную инфраструктуру, «организация» также служит прямым контейнером для некоторых ресурсов, которые было бы странно и неудобно размещать напрямую в тенантах.
В целом слой управления «организацией» настолько заметно отличается с точки зрения сценариев использования и даже набора сотрудников, которые этой «организацией» управляют, что большинство провайдеров уносит web-интерфейс управления организацией на отдельный домен с другой структурой консоли. Если проводить аналогию с чем-нибудь физическим, то консоль управления ресурсами в тенантах — это панель управления космолётом, а интерфейс организации — диспетчерская центра управления полётами.
Внутри тенанта, как правило, обитают разработчики, devops-инженеры — в общем, ИТ-специалисты, ответственные за разработку и развёртывание продуктов и инфраструктуры. С пользователями консоли управления организацией всё несколько сложнее. Обычно это сотрудники клиентской службы ИБ, администраторы AD, финансисты и другие.
Если говорить про облако MWS — в случае «организаций» мы не изобретали велосипед и вводим такой контейнер со старта существования нового облака. Но некоторое количество решений пришлось принять и на этом уровне. Например: «Стоит ли делать организацию обязательным элементом при создании проекта?» Конкуренты зачастую предлагают пользователю просто создать проект. Насколько возможно оценить со стороны, для такого предложения существует как минимум две причины:
— Историческая. Для широкого класса сценариев клиентам хватает тенанта. А значит, первую версию облака можно запускать и без переусложнений в виде «организаций». Но если поддержка организации появляется в сервисе эволюционно для удовлетворения требований более крупных клиентов — провайдер оказывается в биполярной конфигурации с «организационными» и «безорганизационными» тенантами, как минимум на период миграции.
— Продуктовая. Излишняя сложность на пути пользователя при прохождении сценария приводит к снижению конверсии. И хоть цель всей этой статьи в том, чтобы объяснить, что всё это важно и нужно, — фактически облаками пользуются не только крупные enterprise-заказчики, но и менее крупные коммерческие клиенты и даже физлица. И на этой территории начинают действовать правила B2C-сервиса: будь проще или затопчут. Этим объясняется стремление некоторых облаков укатать все сложные enterprise-grade-фичи в отдельные сервисы слоя «организаций» и спрятать их от нового клиента, чтобы не напугать.
Мы решили идти от общего к частному и с точки зрения базовой модели ресурсов (API) нашего облака реализовать сразу «сложную» систему с организациями, внедрёнными в модель сервиса со старта. По задумке это позволит нам сразу ориентироваться на enterprise-клиентов и дизайнить все наши решения относительно сложной версии модели устройства облака, а проблему сложности знакомства с облаком рассматривать как проблему UX.
Фолдеры
Обосновывать необходимость существования тех или иных контейнеров в ресурсных моделях облачных провайдеров становится всё сложнее, но я тем не менее рискну продолжить.
Мы уже разобрались, что сферическая компания в вакууме владеет ровно одной «организацией» в облаке, внутри которой развёрнуто всё разнообразие тенантов, каждый из которых изолирует внутри себя что-то, что нужно изолировать. Например, инфраструктуру для конкретного окружения конкретного продукта компании.
Наверное, уже понятно, к чему я клоню: современные технологические компании могут предоставлять клиентам десятки публичных продуктов. Умножив количество продуктов на количество окружений, клиент получит необходимость управлять довольно длинным плоским списком барахла. Под управлением я понимаю не столько навигацию, сколько централизованное внедрение политик, назначение доступов, аналитику финансов и событий безопасности на более высоком уровне иерархии, чем «окружение продукта», но гранулярнее, чем «на всю организацию». Короче, нужны ещё слои модели, которые позволят выражать схожесть и различия между разными тенантами. Можно, конечно, попробовать подойти к вопросу с умом и типизацией.
Давайте внедрим отдельный слой для окружений и слой для продуктов. Интересно, кстати, какой из этих слоёв должен быть выше? Ну да ладно, продолжим. В некоторых компаниях продукты организуются в продуктовые группы. А ещё бывают бизнес-юниты. И в разных бизнес-юнитах теоретически может быть принята разная модель иерархии продуктов. Кажется, мы тут пытаемся задизайнить структуру идеальной организации для палаты мер и весов.
Тенанты разложены по фолдерам
Чтобы облако не решало за клиента, как должна выглядеть его топология ресурсов, облако предоставляет клиенту «проволоку», из которой клиент может сам собрать каркас своей организации. Фолдеры — единственный контейнер облака, который поддерживает «самовложенность», т. е. работает как директории файловой системы.
На фолдерах можно построить дерево управления ресурсами в соответствии со структурой управления проектами в конкретной организации. Обратите внимание, что фолдеры, про которые я говорю, находятся между «организацией» и «тенантом» и служат связующим звеном между этими мирами.
Изначально я хотел сказать, что фолдеры — это пластилин, но метафора немного не сходилась. Сами по себе фолдеры — довольно скучные и малофункциональные ресурсы, они лишь позволяют очертить контуры модели управления. Пластилином в этой метафоре будет вся мощь org-level сервисов и фичей, которые позволяют применять организационные политики, настраивать аудитное логирование, организовывать контуры доверия и осуществлять контроль и аналитику бюджетов на основе структуры фолдеров. Но это уже совсем другая история.
Сущность Folder в иерархии облаков «Большой тройки»
Последнее размышление о фолдерах. Нейминг среднего слоя, прямо скажем, разнообразный. У меня есть некоторое количество рассуждений на стыке археологии, формальной логики и прочих научных дисциплин о том, почему всё получилось так, как получилось. Но если говорить о принятии решения для нашего нового облака — мы считаем, что название Folder идеально отражает назначение этого ресурса. Фолдер — это абстрактный контейнер, семантику которому придаёт именно клиент облака, а не само облако.
Итого, общая структура ресурсной модели MWS Cloud будет выглядеть вот так:
Вместо заключения
Простой вывод из этой статьи: облако — это сложно. Нет, конечно, у облака есть простые запчасти, но даже они сложны, если пытаться их дизайнить на 5 лет вперёд. А облако — продукт, который нельзя не дизайнить на 5 лет вперёд.
Сейчас мы начинаем цикл статей о построении IAM облачной платформы. Планируем рассказать и о других сущностях и концепциях, которые обитают в IAM:
Субъектах доступа — их видах, способах аутентификации. Управлении субъектами доступа.
Моделях полномочий и ролей.
Непосредственно управлении доступом субъектов к ресурсам.
А с сегодняшней темой об устройстве ресурсной иерархии в облаках пора заканчивать, до встречи в новых статьях, докладах и на каналах!
