Сценарист: Ю Пэнфэй , Мах Чиа Хуэй

Введение

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

Поскольку все больше приложений помещаются в контейнеры, механизмы оркестрации, такие как Kubernetes, становятся чрезвычайно популярными. В качестве механизма оркестрации Kubernetes помогает управлять, масштабировать и развертывать контейнерные приложения. Тем не менее, существует множество различных движков для оркестровки (таких как Docker Swarm) — так почему же Kubernetes остается таким популярным? Быстрый ответ заключается в том, что Kubernetes является многофункциональным, оснащенным такими возможностями, как самовосстановление и автоматическое масштабирование. Кроме того, Kubernetes реализуется как управляемая служба большинством поставщиков облачных услуг (CSP). Это укрепляет его положение в качестве «золотого стандарта» для механизмов оркестровки. Принятие Kubernetes все еще растет: 96% организаций используют или оценивают Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Проблемы с медом

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

Эта статья — первая в нашей серии, посвященной безопасности Kubernetes. В нем будет представлен обзор некоторых распространенных атак и основных рекомендаций по безопасности для Kubernetes. В последующих статьях мы более подробно рассмотрим более сложные атаки, такие как монтирование HostPath, модули/узлы батута и т. д., а также способы их устранения.

Чтобы понять атаки, мы должны сначала понять архитектуру Kubernetes, диаграмма высокого уровня ниже является хорошей отправной точкой. Не стесняйтесь переходить к разделу «Методология атаки», если вы уже знакомы с архитектурой Kubernetes и ее основами.

Схема архитектуры Kubernetes

стручки

Kubernetes состоит из множества движущихся частей, а самая нижняя рабочая единица называется POD . Модуль может содержать несколько различных контейнеров и томов хранения. Каждый модуль также имеет свой уникальный IP-адрес. Он также обладает сверхмасштабируемостью, поскольку основан на схемах развертывания (файл yaml).

Узлы

Чтобы упростить задачу для всех, мы просто разобьем типы узлов на:

● Рабочие узлы

● Главный узел

Набор узлов образует кластер.

Рабочие узлы:

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

Главный узел:

Главный узел является конечным администратором всего кластера. Он контролирует и управляет всеми рабочими узлами, в состав которых входят следующие компоненты: сервер Kube-API, Kube-Controller-Manager, Kube Scheduler и т. д.

Пространство имен

Пространство имен Kubernetes — это механизм изоляции, который изолирует ресурсы внутри кластера, обычно используемый, когда разные команды работают над одним кластером. В контексте кибербезопасности каждый объект/ресурс пространства имен уникален для пространства имен. Вызов объекта/ресурса между пространствами имен невозможен, поскольку эти объекты/ресурсы изолированы в своих пространствах имен.

Теперь, со всеми этими новыми знаниями, вы должны иметь фундаментальное представление о среде Kubernetes. Давайте перейдем к более интересной стороне вопроса: как атаковать Kubernetes?

Методология атаки

Методологию изощренного злоумышленника можно разбить на три этапа.

Этап 1: начальная точка опоры

Основной способ закрепиться — скомпрометировать веб-приложение или микрослужбу, размещенную в кластере. Цель злоумышленника — получить удаленное выполнение кода в приложении путем перечисления приложения и выявления уязвимых мест (например, log4shell, apache struts).

Этап 2. Повышение привилегий

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

Ниже приведены некоторые распространенные методы, которые может использовать злоумышленник:

• Конфиденциальные файлы

Исправление:

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

• Доступные приложения

Исправление:

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

• Облачные службы метаданных

Исправление:

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

• Прорыв капсулы

Исправление:

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

Этап 3: Получение драгоценностей короны

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

В том, что все?

Чтобы получить более полное представление о состоянии безопасности Kubernetes в вашей организации, мы рекомендуем вам использовать матрицу атак Kubernetes от Microsoft. Матрица включает в себя основные тактики, относящиеся к безопасности Kubernetes. Каждый из них содержит несколько методов, которые злоумышленники могут использовать для достижения различных целей.

Заключение

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

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

Будьте осторожны и поймайте вас на FLIPPETY-FLIP.