Один бит меняет следующий. Фронтенд ведет диалог с бэкендом. Все в ИТ строится вокруг удостоверения, вокруг того, что с чем взаимодействует и каков результат этого взаимодействия. Команда VK Cloud перевела статью о переходе от IP к identity, или удостоверениям.

Немного вводных

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

Наиболее фундаментальная и мощная абстракция облачных решений — это уход от статических IP-адресов и серверов к удостоверениям, в основе которых лежат заменяемые элементы на основе метаданных нагрузки. Абстрагируясь от индивидуальной рабочей нагрузки и переходя на удостоверение группы сущностей, мы переходим с заботы об отдельных питомцах на выпас стада. И тогда работа в облачной среде становится возможной и эффективной. В облачной среде низкоуровневые конструкты вроде IP-адреса и ID процесса связаны с высокоуровневыми конструктами вроде меток в Kubernetes. Благодаря этому мы стали совершенно по-другому продумывать, проектировать и управлять ИТ-системами и инфраструктурой. Многие фундаментальные концепции остались прежними, но благодаря удостоверениям в эпоху облачных технологий значительно изменился масштаб. 

Kubernetes, Cilium и другие облачные проекты переняли идею масштабируемых удостоверений — они стали ключевой концепцией этих платформ. Раньше нужно было вписывать IP-адреса в код приложений. Сейчас фронтенд может «разговаривать» с бэкендом даже во время обновления или замены сервера или сети. Сервисы и приложения перестали быть питомцами, о которых надо заботиться. Теперь это абстрактное стадо, скрывающееся под «облачным» удостоверением. В этой статье мы проследим эволюцию удостоверений в системном программировании вплоть до нынешней эпохи облачных технологий и расскажем, как сегодня удостоверение стало тем самым ключом к созданию высокоэффективных платформ в облачных проектах вроде Kubernetes и Cilium.

Удостоверение как основополагающая системная концепция

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

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

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

Связь удостоверений с безопасностью и распределением ресурсов позволила создавать контейнеры с помощью cgroups и пространств имен. Если мы работаем не с отдельным сервером, а с сетью устройств, удостоверения становятся еще более необходимыми. Без них серверы не знали бы, с кем взаимодействовать или как друг друга найти. Долгое время специалисты в области сетевых технологий пытались разобраться, как автоматически выдавать удостоверение потокам в сети. Работаете ли вы с одним или со многими серверами, удостоверения — это краеугольный камень наших систем и платформ.

Сохраненные IP-адреса и имена серверов: пределы есть

Сначала удостоверения серверов в сети представляли собой адрес, по которому их могли найти другие устройства. Чаще всего это был IP-адрес. Такой подход работал, когда люди могли сохранять IP-адреса, выбирать для серверов имена в честь любимой компьютерной игры или телепередачи и записывать их в электронную таблицу. Однако статические IP-адреса и резервирование по протоколу DHCP не бесконечны. Такие ограничения обусловлены человеческим фактором, сложностью системы и эксплуатационными расходами.

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

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


Соединения на основе IP до эпохи облачных технологий

Удостоверения в облачных решениях: домашний скот вместо питомцев

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

В облаке не думают об отдельно взятой сущности. В нем используется удостоверение, абстрактно представляющее скорее расходные заменяемые ресурсы, а не постоянные уникальные сущности. Отношение к инфраструктуре как к стаду с абстрактным удостоверением играет ключевую роль для облачных решений, поскольку такой подход обеспечивает стандартизированный способ идентификации и аутентификации ресурсов. Теперь можно не полагаться на присвоение IP-адресов и имен серверов вручную: управлять и группой ресурсов с единым удостоверением можно автоматически. Ресурсы можно легко добавлять, удалять и заменять без ручного вмешательства и почти прозрачно для конечного пользователя. Этот подход улучшает безопасность и комплаенс, так как позволяет реализовать масштабируемый аудит и контроль доступа на основе удостоверений. Благодаря обращению с ресурсами и системами как с «расходным материалом» и использованию стандартизированных механизмов работы с удостоверениями в облаке повышается эффективность, масштабируемость и безопасность управления инфраструктурой. На нескольких примерах покажу, как в реальных облачных проектах изменилась работа с удостоверениями.


В облачных проектах удостоверение выступает абстракцией для связи систем

Удостоверения в реальных проектах Kubernetes

Kubernetes преобразил управление инфраструктурой, позволив пользователям декларировать, что им нужно, — а система позаботится обо всем остальном. Если что-то пойдет не так, она автоматически возвращается в нужное состояние. Вдруг оказалось, что пользователи просто могут декларировать требование «Мне нужно три реплики фронтенда», а Kubernetes самостоятельно настроит приложение и с помощью сервисов предоставит его кому надо. Козырь Kubernetes в том, что он создает и управляет метаданными удостоверений, которые другие элементы Kubernetes и инструменты облачной экосистемы могут использовать для взаимодействия с приложением.

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

В мире Kubernetes все совершенно по-другому. Пользователи все так же обращаются к приложению через IP-адрес, но он поддерживается сервисом Kubernetes, который соответствует набору реплик с взаимозаменяемыми подами. Используя метки на подах и IP-адресах кластеров, сервис Kubernetes автоматически поддерживает актуальную информацию об удостоверениях, позволяя пользователю обращаться к приложению, а приложению — к базе данных даже при замене подов, серверов и IP-адресов. Сервис Kubernetes предоставляет удостоверение, в котором поды и их IP-адреса представлены как абстракция.


Сервис Kubernetes предоставляет удостоверение группы подов

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

Cilium Identity: сеть, наблюдаемость и безопасность

Cilium — это платформа сетевого взаимодействия, обеспечивающая безопасность и наблюдаемость в сети. Она берет низкоуровневые сетевые конструкты вроде IP-адреса, высокоуровневые конструкты Kubernetes вроде меток, объединяет их и создает Cilium Identity. Используя Cilium Identity как ключевой компонент платформы, Cilium может гибко решать разные задачи в облачных средах: объединять несколько кластеров, упрощать наблюдаемость, поддерживать функцию service mesh и даже применять облачные инструменты за пределами Kubernetes.


 Удостоверения — основной конструкт в Cilium

Cilium создали как обычный сетевой CNI; с течением времени однако деплойменты Kubernetes стали все чаще охватывать множество кластеров. Поскольку Cilium и так присваивает удостоверение всему, что есть в кластере, это позволяет без проблем расширить применение удостоверений на уровне нескольких кластеров. И вдруг оказывается, что ваше приложение берет информацию не из одной, а из нескольких баз данных в разных кластерах. Это удобно для сценариев, когда локальная база данных недоступна из-за обновлений или сбоев в работе. Приложение продолжает работать нормально, потому что оно переключилось на удаленный кластер. Сетевые политики также можно применять глобально: это позволяет, в частности, блокировать межкластерный трафик между клиентами, и при этом разрешать входящий трафик из разных кластеров.

Облачные решения перешли на модель управления стадами, потому что в любой момент что-то может пойти не так, и в этом случае нужно выяснить, что именно вышло из строя, и починить это. Опять же, Hubble обеспечивает наблюдаемость, объединяя низкоуровневые конструкты вроде IP-адреса с высокоуровневыми вроде подов или пространств имен в Kubernetes. Если трафик между двумя IP-адресами направляется неправильно, система не станет изучать tcpdump и сопоставлять IP-адреса. Она скажет вам, в каких подах локализуется проблема и какие сетевые политики применялись к пространствам имен, в которых находятся поды. Эту информацию также можно экспортировать и связать с удостоверением, обеспечив непротиворечивое представление наблюдаемости на уровне метрик, логов и трассировок.

Service mesh, при всем хайпе по поводу ее функций вроде взвешенной маршрутизации, ограничения скорости обработки запросов и mTLS, прежде всего основывается на идее, что конфигурация определяет рабочую нагрузку. В традиционной service mesh паттерн sidecar был нужен, чтобы выдавать удостоверения рабочей нагрузке и, в частности, проверять их парой ключей TLS для mTLS. Но поскольку Cilium и так выдает рабочим нагрузкам сетевое удостоверение, в этом решении можно реализовать функции service mesh без паттернов sidecar совершенно прозрачно для конечного пользователя. Например, при взаимной аутентификации Cilium автоматически связывает удостоверения с парами ключей TLS.

Наконец, за пределами Kubernetes возможна и интеграция в традиционные рабочие нагрузки: Cilium Mesh добавляет Cilium Identity к любой рабочей нагрузке в сети, соединяя кластеры Kubernetes, виртуальные машины и физические серверы, работающие в облаке, в локальной среде или на периферии. Cilium Mesh выводит функций сетевого взаимодействия, наблюдаемости и безопасности на основе Cilium за пределы облачных сред, используя в составе Cilium Identity метаданные не из Kubernetes. В Cilium канал передачи данных всегда был универсальным. Благодаря подходу к сетевым удостоверениям в этом решении всегда поддерживались сценарии использования, применимые не только к Kubernetes. Тот факт, что несколько пользователей используют Cilium лишь как vSwitch в средах вроде OpenStack и Cilium Mesh, просто официально расширяет масштабы решения.


Поскольку в Cilium Mesh используется преимущественно удостоверение, а не IP-адрес, в нем формируется системный подход к управлению рабочими нагрузками Kubernetes, виртуальными машинами и физическими серверами, работающими в облаке, в локальной среде или на периферии

Cilium может обеспечить системный подход к управлению кластерами, наблюдаемостью, service mesh и системами за пределами Kubernetes, поскольку в этой платформе все строится вокруг удостоверения. Благодаря удостоверениям облачные сетевые решения, наблюдаемость и безопасность прошли путь от заботы о питомцах до выпаса стада быков.

Облачные быки — конструкты удостоверений

Благодаря эволюции удостоверений в системном программировании стала возможна разработка облачных платформ, более динамичных, масштабируемых и эффективных, чем какие-либо ранее существовавшие решения. Удостоверения сыграли критически важную роль в разработке ИТ-систем, инфраструктуры и платформ благодаря переходу от базовых понятий ID процесса и пользователя к современной абстракции рабочих нагрузок на основе заменяемых ресурсов. С появлением облачных технологий, таких как Kubernetes и Cilium, сервисы и приложения можно воспринимать не как питомцев, а как стадо, абстрактно представленное удостоверением, которое обеспечивает масштабируемость, простоту эксплуатации и устранения неисправностей, высокую надежность системы и эффективное распределение ресурсов. По мере дальнейшего развития отрасли удостоверение, без сомнения, останется важнейшим понятием в системном программировании, позволяя создавать все более мощные инновационные платформы.

Вы прямо сейчас можете воспользоваться Kubernetes от VK Cloud. Для тестирования мы начисляем новым пользователям 3 000 бонусных рублей и будем рады вашей обратной связи.

Stay tuned

Присоединяйтесь к Telegram-каналу «Вокруг Kubernetes», чтобы быть в курсе новостей из мира K8s: регулярные дайджесты, полезные статьи, а также анонсы конференций и вебинаров.