Технологии контейнеризации в последние годы получили широкое распространение и наиболее известным решением по управлению контейнерами по праву считается Kubernetes, или, сокращенно, K8s. Kubernetes это система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими. Данная система построена на базе программного обеспечения с открытым исходным кодом. Изначально решение разрабатывалось специалистами Google, начиная с 2014 года и предназначалось для решения внутренних задач корпорации. Однако, впоследствии Kubernetes стал решением Open-Source и получили широкое распространение по всему миру.
Kubernetes, как система управления кластерами из контейнеров, является динамическим решением, которое позволяет в режиме реального времени реагировать на события, оживлять “упавшие” сервисы и масштабироваться по запросу. Особенно преимущества Kubernetes в части живучести оценили разработчики. В качестве примера можно привести историю, когда у помещенного в контейнеры приложения начала “течь” память. Однако, разработчики узнали об этом только через несколько месяцев, когда заинтересовались, логами приложения. А все это время Kubernetes исправно следил за контейнерами с этими приложениями и в случае их “подвисания” тут же рестартовал их. Так что живучесть контейнеризированным приложениям данная система обеспечивает на “отлично”.
В целом, K8s можно назвать стандартом для современных DevOps-сред в организациях различного уровня. Например, Kubernetes используется в таких облачных сервисах, как: AWS, Microsoft Azure или Google Cloud.
Немного об устройстве
Но, как и всякое программное обеспечение Kubernetes не лишен проблем с безопасностью. Однако, прежде чем начать разговор об этих проблемах, необходимо познакомиться с архитектурой данного решения. Схематически, основные компоненты архитектуры Kubernetes представлены на следующем рисунке.
Пожалуй, основным понятием администрирования Kubernetes является понятие подов (pods). Под является группой контейнеров, объединенных общей задачей, которые могут быть, как микросервисом, так и серьезным приложением, работающим на нескольких машинах. K8s распределяет нагрузку между узлами кластера, перераспределяя контейнеры в зависимости от текущей нагрузки, потребности в тех или иных сервисах, балансировки нагрузки и т.д.
Основными компонентами K8s являются:
Master Node — главный мастер-сервер, который управляет всем кластером подов;
Worker Node — рабочие серверы, на которых запускают контейнеры приложений и другие компоненты Kubernetes;
Pods — это основной элемент, с которым работает в Kubernetes, имеющий собственный IP-адрес;
Services — сетевые службы, обеспечивающие работу кластера;
System Components — ключевые системные компоненты, которые используются для управления кластером Kubernetes.
Резюмируя, стоит отметить, что основными задачами, решаемыми Кubernetes являются запуск и управление большого количества контейнеров на множестве физических машин, мониторинг состояния контейнеров и своевременное реагирование на изменения, а также масштабирование и балансировка контейнеров и в пределах кластера.
Какие бывают уязвимости
Теперь перейдем к проблемам безопасности. Но начнем мы не столько с обсуждения уязвимостей самого K8s, сколько с общего понимая существующих типов.
Все уязвимости можно разделить на три типа:
Проектирования
Реализации
Эксплуатации
Уязвимости проектирования – ошибки допущенные при построении архитектуры программного продукта, протокола, устройства (например, передача всех данных в открытом виде в протоколах Telnet, HTTP, FTP). То есть, те ошибки которые допустили архитекторы и проектировщики решения при построении его архитектуры.
Уязвимости реализации – ошибки, допущенные разработчиками при создании решения. Например, различные ошибки переполнения буфера, уязвимости форматной строки и прочее. По сути, это ошибки программистов при написании кода приложения.
Уязвимости эксплуатации – ошибки допущенные в процессе эксплуатации программного продукта, протокола, устройства и т.д. Например, заводские пароли и дефолтные настройки безопасности, использование небезопасных сервисов, простых паролей и т.д. Здесь речь идет уже о “кривых руках” тех, кто обслуживает систему. Как бы хорошо не была спроектирована и реализована система, небезопасные настройки могут существенно снизить общий уровень ее защищенности.
Уязвимости проектирования
Начнем с уязвимостей проектирования. Конечно, назвать архитектуру K8s уязвимой по умолчанию нельзя. Как видно из представленной выше схемы, Kubernetes имеет довольно сложную архитектуру, состоящую из нескольких компонентов и конечно возможны ситуации, когда злоумышленники могут воспользоваться архитектурными особенностями конкретной реализации, для осуществления своих целей. Например, если контейнеры динамически развернуты в нескольких независимых друг от друга облаках, это может значительно увеличивать трафик обмена данными внутри логического кластера. Зная о географическом удалении контейнеров, хакер может попытаться, выводя из строя контейнеры в одном из облаков осуществить DDoS атаку на канал между облаками, так как контейнеры будут часто переезжать, создавая нагрузку на канал.
Уязвимости реализации
В отличии от уязвимостей проектирования, с багами программистов все несколько проще в плане обнаружения, но от этого не сильно легче.
Возьмем, к примеру уязвимость CVE-2019–1002101, связанную с проблемами в интерфейсе командной строки kubectl для управления Kubernetes. Суть уязвимости заключается в том, что во время процесса копирования файлов с помощью команды cp в контейнере создается бинарный файл архива tar, который затем передается по сети и распаковывается kubectl на устройстве пользователя. Но при наличии вредоносного файла tar в контейнере, злоумышленник может внедрить произвольные файлы в любое место системы, похитить конфиденциальную информацию и запустить произвольное приложение с работающими правами kubectl, в том числе с правами root. Еще одна уязвимость CVE-2019–5736, даёт заражённому контейнеру возможность перезаписать исполняемый файл на хосте и получить к нему root-доступ.
В марте 2019 года обнаружена подобная предыдущей уязвимость CVE-2019–11246, которая позволяет атакующему доставлять файлы из пода на компьютер оператора или модифицировать их с помощью подмены выполняемого двоичного файла tar, используя обычную внутреннюю команду kubectl cp.
На профильных ресурсах, таких, как база данных уязвимостей CVE можно найти множество различных вариантов эксплуатации багов в программном коде Kubernetes. Причем многие уязвимости будут довольно свежими, датированными уже 2022 годом. Однако, как правило, ко всем этим уязвимостям разработчики оперативно выпускают патчи и на момент публикации уязвимости эти обновления уже выпущены. Поэтому, если своевременно устанавливать обновления безопасности, то угроза успешной эксплуатации этих уязвимостей может быть существенно снижена.
Уязвимости эксплуатации
Уязвимости небезопасной настройки зачастую выявить бывает сложнее. В качестве примера можно взять атаку компрометация контейнера. В случае, когда контейнеры в кластере небезопасно настроены, то есть используют простые пароли, небезопасные сервисы или же уязвимые приложения, возможна ситуация, когда злоумышленники, получив доступ к отдельным контейнерам сможет затем скомпрометировать все приложение, или значительную часть его компонент. А ведь возможность изолированного выполнения кода в контейнерах является одной из основных фич Kubernetes.
Частным случаем неверной настройки кластера является возможность несанкционированных соединений между подами внутри единого кластера. В таком случае, скомпрометированные контейнеры могут соединяться с другими контейнерами на том же или на других хостах, чтобы запустить какую-либо атаку. При правильной настройке сети такую атаку можно предотвратить посредством разделения подов на L2 или L3, однако в некоторых случаях, реализация данной атаки вполне возможна.
Заключение
В этой статье мы поговорили о том, что из себя представляет решение Kubernetes, рассмотрели основные компоненты его архитектуры и обсудили те виды уязвимостей, которые можно встретить в его программных компонентах и их настройках.
В следующей статье мы рассмотрим, какими средствами можно обнаружить уязвимости и небезопасные настройки в K8s, и о том, как можно защититься от возможных атак. А прямо сейчас хочу пригласить вас на бесплатный вебинар по теме: "Почему безопасность должна быть на всех этапах CI/CD". Регистрация доступна по ссылке.