Kubernetes

Kubernetes — проект с открытым исходным кодом, предназначенный для управления кластером контейнеров Linux как единой системой в микросервисной архитектуре. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а также обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google, а затем к нему подключились многие крупные ИТ-компании, включая Microsoft, Red Hat, IBM и Docker.

2022

Kubernetes 1.26

В начале декабря 2022 года была представлена обновленная версия Kubernetes — 1.26. Kubernetes (или сокращенно K8s) — это открытое программное обеспечение для оркестровки контейнеризированных приложений, автоматизации их развёртывания, масштабирования и управления в условиях кластера. В данной версии появился функционал, предложенный и реализованный компанией «Флант», — он был принят разработчиками платформы как Kubernetes Enhancement Proposal (KEP). Об этом 26 декабря 2022 года сообщила компания «Флант».

Kubernetes

По информации компании, архитектор Kubernetes-платформы Deckhouse компании Флант Максим Набоких указал разработчикам K8s на недостающую функциональность в API проекта, которая в значительной степени оптимизировала бы получение сведений о том, какой аутентификатор используется и какие права доступа будут выданы пользователю. Предложение Максима, особенно актуальное в случаях применения сложного процесса аутентификации в Kubernetes-кластерах, получило поддержку среди ответственных за направление аутентификации и авторизации в проекте Kubernetes. Впоследствии оно было реализовано его же силами и представлено в статусе альфа-версии в релизе Kubernetes 1.26.

Поскольку Kubernetes — это Open Source-проект, на декабрь 2022 года в его разработке участвует всё мировое сообщество. Среди компаний, которые вносят изменения в кодовую базу Kubernetes, такие ИТ-корпорации, как Google, Red Hat, VMware, Microsoft, IBM и многие другие. Для того, чтобы изменение в Kubernetes приняли, оно должно пройти одобрение от технического комитета, ответственного за конкретные компоненты проекта. Когда изменение становится достаточно существенным, его необходимо сопроводить документацией в виде KEP, где описываются и согласовываются подробности о том, зачем нужны предлагаемые изменения, какие проблемы они решают и какой подход принят при реализации.Обзор российского рынка банковской цифровизации: импортозамещение, искусственный интеллект и собственные экосистемы 7.6 т

Каждый релиз Kubernetes включает в себя ряд исправлений к старой функциональности и обновленные возможности, задокументированные в KEP. Изменения сначала появляются в статусе Alpha, чтобы все пользователи Kubenetes могли протестировать их в своих инсталляциях и убедиться в корректной работе. Уровень стабильности этих функций постепенно повышается (до Beta, а затем и до GA) с последующими релизами проекта.

Основной дистрибутив Kubernetes, который развивается как Open Source-проект с официальными релизами от мирового сообщества, называют «ванильным» — другими словами, оригинальным, т.е. без какого-либо специфичного функционала от вендоров, а только с функциями, одобренными всем сообществом. Затем на основе ванильного Kubernetes вендоры создают собственные Kubernetes-платформы.

Как начать работу с Kubernetes

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

Более 380 000 серверов API Kubernetes недостаточно защищены

18 мая 2022 года стало известно о том, что более 380 000 серверов API Kubernetes недостаточно защищены.

Большая часть уязвимых серверов находится в США, остальные – в Западной Европе, Юго-Восточной Азии и Австралии.

После очередного ежедневного сканирования пространства IPv4 по портам 443 и 6443 в поисках IP-адресов, которые отвечают статусом HTTP 200 OK, ShadowServer обнаружил 381 645 экземпляров API Kubernetes, ответивших "200 OK", что говорит об успешном выполнении запроса. Это не говорит о полном отсутствии защиты у серверов, но организация считает, что они представляют собой неоправданно открытую поверхность для атак злоумышленников.

Проведенное организацией сканирование также показывало версию Kubernetes (наиболее популярными оказались версии с 1.17 по 1.22) и платформу (на Linux/AMD64 пришлось подавляющее большинство открытых экземпляров).

Пользователи, подписанные на рассылку ShadowServer, получат данные об открытых экземплярах Kubernetes в их сети абсолютно бесплатно. Подписчикам, получившим уведомления об открытых экземплярах API, специалисты рекомендуют ознакомиться с официальным руководством по обеспечению безопасности доступа к API Kubernetes^[1].

Выход Kubernetes 1.24

5 мая 2022 года стало известно, что доступен релиз платформы оркестровки контейнеров Kubernetes 1.24, позволяющей как единым целым управлять кластером из изолированных контейнеров и предоставляющей механизмы для развёртывания, сопровождения и масштабирования выполняемых в контейнерах приложений. Проект изначально был создан компанией Google, но затем переведён на независимую площадку, курируемую организацией Linux Foundation. Платформа позиционируется как развиваемое сообществом универсальное решение, не привязанное к отдельным системам и способное работать с любыми приложениями в любых облачных окружениях. Код Kubernetes написан на языке Go и распространяется под лицензией Apache 2.0.

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

Ключевые изменения в данном выпуске:

• Стабилизированы средства для отслеживания ёмкости хранилища (Storage Capacity Tracking), обеспечивающие мониторинг свободного места в разделах и передающие данные на управляющий узел для предотвращения запуска pod-ов на узлах, на которых недостаточно свободного места.
• Стабилизирована возможность расширения разделов хранилища. Пользователь может изменить размер уже существующих разделов, и Kubernetes автоматически без остановки работы расширит раздел и связанную с ним файловую систему.
• Прекращена поставка runtime Dockershim, который позиционировался как временное решение для использования Docker в Kubernetes, не совместимое со штатным интерфейсом CRI (container runtime interface) и приводящее к дополнительному усложнению kubelet. Для управления изолированными контейнерами следует использовать runtime, поддерживающий интерфейс CRI, такой как containerd и CRI-O, или воспользоваться обвязкой cri-dockerd, реализующей интерфейс CRI над API Docker Engine.
• Предоставлена экспериментальная поддержка верификации образов контейнеров по цифровым подписям с использованием сервиса Sigstore, ведущего публичный лог для подтверждения подлинности (transparency log). Для предотвращения supply chain атак и подмены компонентов также обеспечено заверение цифровыми подписями связанных с релизами артефактов, в том числе всех устанавливаемых исполняемых файлов Kubernetes.
• По умолчанию в кластерах прекращено включение API, находящихся в состоянии бета-версии (добавленные в прошлых выпусках тестовые API сохранены, изменение касается только актуальных API).
• Реализована тестовая поддержка формата OpenAPI v3.
• Представлена инициатива по переводу плагинов для работы с хранилищами на унифицированный интерфейс CSI (Container Storage Interface) с сохранением совместимости на уровне API. На CSI переведены плагины Azure Disk и OpenStack Cinder.
• На стадию бета-тестирования переведён Kubelet Credential Provider, позволяющий динамически извлекать учётные данные для репозитория образов контейнеров через запуск плагинов, без хранения учётных данных в файловой системе узла.
• Предоставлена возможность резервирования диапазона IP-адресов для назначения сервисам. При включении данной опции кластер будет автоматически назначать сервисам только IP-адреса из заранее выделенного для каждого сервиса пула, что позволяет избежать возникновения коллизий при выдаче свободных адресов из общего набора.^[2]

2019

Commvault представила сервис для контейнеров - Metallic BaaS для Kubernetes

18 ноября 2020 года Commvault, компания в области программного обеспечения корпоративного класса для управления данными в облачных и локальных средах, объявила о доступности сервиса Metallic BaaS для Kubernetes. Подробнее здесь.

HPE представила контейнерную платформу на базе Kubernetes

В ноябре 2019 года Hewlett Packard Enterprise (HPE) представила, как утверждает компания, первую на рынке контейнерную платформу корпоративного класса на базе Kubernetes. Решение получило название HPE Container Platform. Подробнее здесь.

Сила Open Sourсe: Как Kubernetes заставил VMware поменять архитектуру флагманского продукта

В ноябре 2019 года VMware объявила о выходе бета-версии своего нового проекта – Project Pacific, над которым компания работала около трех лет. Он предлагает набор средств для преобразования vSphere – флагманского продукта VMware – в нативную платформу для кластеров Kubernetes. Пока Project Pacific открыт для ограниченного круга заказчиков. Позже он должен стать доступен более широкому кругу клиентов, а затем - появиться в новых релизах vSphere. Подробнее здесь.

Поддержка Windows

В конце марта 2019 года вышла версия Kubernetes 1.14, в которая появилась полноценная поддержка Windows-контейнеров. Ранее такая функция была доступна только в тестовом режиме.

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

В платформе для приложений Kubernetes появилась поддержка Windows

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

В Red Hat назвали официальную поддержку Windows «кульминацией огромного объема работы за последний год».

Помимо поддержки Windows-узлов, платформа для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями получили еще примерно три десятка новых возможностей. Среди наиболее важных стоит отметить то, что динамические отказоустойчивые кластеры Kubernetes теперь можно создавать с помощью привычных (в контексте кластеров с одним узлом) команд kubeadm (init и join). Другие изменения:

• Для Windows-инсталляций появилась альфа-версия поддержки gMSA (Group Managed Service Account) — специальных учётных записей в Active Directory, которые могут использоваться и контейнерами.

• Официальная поддержка CoreDNS

• Поддержка больших страниц 

• Обновились логотип kubectl и его документация 

• kubectl научили копировать файлы, выбираемые с помощью wild card.

Kubernetes остается одним из самых популярных проектов на GitHub, у которого насчитывается более 6500 участников (на конец марта 2019 года). Популярность платформы обусловлена растущим интересом компаний к микросервисной архитектуре. На фоне высокого спроса поддержка Windows была делом времени.^[3]

2018

Эксплоиты для уязвимости в Kubernetes

11 декабря 2018 года Securitylab сообщил, что новость о недавно обнаруженной уязвимости в Kubernetes серьезно всколыхнула ИБ-сообщество. На 11 декабря 2018 года появился уже целый ряд демо-эксплоитов для нее в совокупности с доступными инструкциями.

Уязвимость позволяет неавторизованному пользователю повысить свои привилегии и запускать команды для получения полного контроля над узлом. С помощью особым образом сконфигурированных запросов атакующий может установить связь с конечным сервером через сервер Kubernetes API. Настройки системы по умолчанию позволяют любому пользователю, как авторизованному, так и неавторизованному, отправлять запросы на обнаружение API, что существенно облегчает задачу злоумышленникам.

Исправление для уязвимости существует, однако, как отметил исследователь из Twistlock Ариэль Зеливански (Ariel Zelivansky), его «невозможно применить без того, чтобы не сломать что-то в кластере». Единственный надежный способ защититься от атак – обновить Kubernetes до версии 1.10.11, 1.11.5, 1.12.3 или 1.13.0-rc.1.

Вскоре после обнаружения уязвимости Зеливански написал простой скрипт на Ruby для атаки на агрегатор metrics-server, используемый для мониторинга ресурсов ЦП и RAM контейнера (metrics-server использует функцию расширений для сервера API). В опубликованном им видео показано, как эксплоит позволяет получить информацию о модулях из всех пространств имен в кластере. Скрипт может быть выполнен из любого модуля и работает при условии развертывания metrics-server и дефолтной конфигурации.

5 декабря, всего через два дня после раскрытия уязвимости, свой PoC-эксплоит опубликовала на GitHub компания Gravitational. Инструмент представляет собой утилиту для проверки наличия уязвимости в кластере Kubernetes. Однако, как предупредили разработчики, утилита может выдавать «некорректные результаты при определенных обстоятельствах».

Третий эксплоит был представлен пользователем Twitter под псевдонимом Vincent. Изначально с его помощью неавторизованный пользователь мог похитить информацию из модуля etcd-kubernetes, где по умолчанию хранятся критически важные данные^[4].

Первая серьезная уязвимость

В декабре 2018 года стало известно о первой серьезной уязвимости Kubernetes. Поскольку эта платформа оркестровки контейнеров стала популярной, появление «дыр» в ее защите был делом времени, отмечает портал ZDNet.

Серьезность уязвимости, получившей обозначение CVE-2018-1002105, была оценена 9,8 баллов из 10 возможных по шкале CVSS. Используя эту брешь, хакеры могли установить соединение с API внутреннего сервера (backend) при помощи специально подготовленного сетевого запроса, а затем отправлять произвольные запросы самому бэкэнду. Уязвимые установки Kubernetes позволяли проделать все это, используя учетные данные TLS для API-сервера. Об этой проблеме сообщили в компании Rancher Labs, предлагающей решение вида «Kubernetes как услуга» (Kubernetes-as-a-Service).

В Kubernetes найдена первая серьезная уязвимость

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

Для устранения необходимо обновить Kubernetes до версий 1.10.11, 1.11.5, 1.12.3 и 1.13.0 или хотя бы блокировать анонимный доступ к API при помощи опции anonymous-auth=false, а также аннулировать права на выполнение операций exec/attach/portforward.^[5]

Примечания