IAM или Identity & Access Management это система из сервисов, отвечающих за то, что только обладающие нужными правами пользователи, программы и другие сервисы могут совершать операции над ресурсами в Облаке (CloudMTS).
Центральный компонент IAM – это сервис проверки полномочий, или Access Service. Он проверяет, что тот, кто совершает действие над ресурсом облака, имеет право это делать. Это ответственный сервис, от работоспособности которого зависит доступность всего облака. Поэтому отказоустойчивость при сверхвысокой нагрузке – необходимое требование, которое мы учитываем в процессе разработки и проектирования.
Управлением учетными записями пользователей, распределение пользователей по отделам, назначение ролей как на пользователя, так и на отдел или организацию – непростые задачи. В современном мире клиенты облака полагаются на разнообразные системы управления сотрудниками: AD, OIDC/SAML-совместимые on-prem или aaS решения, ЕСИА. Поддержка интеграции с такими системами позволяет нашим клиентам управлять доступами своих сотрудников к облачным ресурсам удобно и безопасно.
Сервисные аккаунты позволяют выполнять действия в облаке без участия человека. Технические учетные записи в первую очередь отличаются от "человеческих" учеток способами аутентификации программы, сервиса или процесса перед облаком. Задача сервисного аккаунта – предоставить программный доступ к ресурсам облака одновременно удобно и безопасно. Различные сценарии: запуск скрипта в виртуальной машине облака, на ноутбуке разработчика или в облачном ресурсе другого провайдера - требуют разных способов аутентификации роботного пользователя в облаке.
Учет и организация ресурсов – задача, которая встает перед любым клиентом облака. Особенно высокие требования к возможностям управления и контроля над ресурсами предъявляет крупный бизнес. Любой облачный провайдер реализует свое чувство прекрасного в ресурсной иерархии своего облака: организации, фолдеры, проекты и прочие контейнеры используются клиентами для решения задач учета и контроля бюджета и прав доступа, а так же для навигации по множеству облачных объектов. Ресурсную иерархию облака "приводят в движение" сервисы группы Organizations & Resource Management, за разработку которых отвечает команда IAM.
Безопасность и защита данных в приоритете. Любое современное облако предоставляет клиентам разноообразные сервисы, а ценность облака как платформы определяется в том числе количеством и качеством интеграций облачных продуктов между собой. Внутреннее взаимодействие сервисов современного облака не может быть построено на принципе доверия "всех всем". В сценариях межсервисного взаимодействия, помимо соблюдения "least privilege principle", облако должно предоставлять клиенту понятные принципы управления цепочками доверия между клиентом, его ресурсами и сервисами облака. Проектирование межсервисного взаимодействия в облаке – отдельная интересная задача, которую решает наша команда.
Упрощенный kanban позволяет двигаться к цели достаточно гибко. При этом ежедневные стендапы позволяют команде не терять понимания о текущих задачах и проблемах, помогать друг другу в сложных ситуациях. В качестве системы управления задачами и досками задач используется JIRA.
💡 Все сервисы мы пишем на Kotlin или Java, в качестве базы данных используем PostgreSQL. И внутренний, и публичный API облака реализуют REST на базе penAPI-спецификации.
OpenAPI first. Сначала в отдельном репозитории создается спецификация OpenAPI, а весь серверный и клиентский код генерируется при сборке сервисов на соответствующем языке программирования. Такой подход позволяет отслеживать обратную совместимость, и создавать сервисы буквально по кнопке, концентрируясь на реализации протокола.
💡 Команда сама отвечает за работоспособность своих сервисов. Ротация дежурных за сервис позволяет поддерживать облако работспособным 24/7.
Первый приоритет сервиса IAM – стабильная и надежная работа. Проблемы в сервисе IAM сразу же отражаются на всем Облаке, поэтому мы уделяем огромное внимание стабильности сервиса и его работоспособности при различных отказах. Наш сервис остается работоспособным при отказе базы данных, отказах дисков виртуальных машин, при потере связи в одной из зон доступности, при периодических проблемах с сетью и так далее.
Мы используем Golang для написания вспомогательных утилит, нагрузочного и end to end тестирования сервисов, а также для разработки CLI и Terraform-провайдера.
💡 Зачастую нам важнее задержать релиз новой функциональности нежели допустить простой сервиса в течение нескольких секунд. Качество, стабильность и надежность работы – всегда наш главный приоритет.
Важным аспектом стабильности сервиса является минимизация вероятности попадания багов в продакшен. Для этого мы используем хорошо зарекомендовавшие себя подходы: TDD(разработка через тестирование), BDD(разработка через фиксацию поведения сервиса) и другие.
💡 Все изменения в сервисах IAM проходят различные этапы контроля – анализ со стороны ИБ, peer-review, автоматический контроль в процессе SSDL (безопасной разработки).
Крупные изменения проходят процесс внутреннего дизайн-ревью, на котором команда обсуждает различные подходы к решнию задачи – их плюсы и минусы. Как известно, в systems design нет идеального решения, а любое решение – это всегда набор компромиссов.
В команде IAM можно выделить четыре основных класса задач: