Самое известное средство контейнеризации и автоматизации развертывания приложений — Docker. Известное, но не единственное: достойную конкуренцию ему составляет Kubernetes. Разумеется, он тоже представляет определенный интерес для злоумышленников. Как защитить Kubernetes от взлома и сетевых атак? Об этом — сегодняшняя статья.
В прошлой статье я рассказал о том, как проверить текущий уровень защищенности очень популярной в DevOps-среде системы контейнеризации Docker и как повысить этот самый уровень. Сегодня мы продолжим изучать вопросы безопасности DevOps-инфраструктуры, и у нас под прицелом система контейнерной оркестрации на базе Kubernetes. Мы разберем основные векторы атак, изучим нашумевшие уязвимости, а также соберем набор инструментов, необходимый для обеспечения безопасности кластера на Kubernetes. Приступим!
Я думаю, каждый, кто хотя бы однажды сталкивался с миром DevOps, имеет общее представление о том, что такое Kubernetes. Если кратко, то это довольно популярная система контейнерной оркестрации (правда, к музыке и оркестрам она не имеет ни малейшего отношения). На чем основывается популярность Kubernetes и чем он так хорош?
Kubernetes, или, сокращенно, K8s, — система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими, реализованная на базе открытого программного обеспечения. Проект был основан в 2014 году. Оригинальная версия некогда разрабатывалась в недрах самой Google для внутренних нужд корпорации, но впоследствии была передана под управление опенсорсному фонду Cloud Native Computing Foundation, откуда и попала в широкие массы.
Изначально K8s задумывалась как система-менеджер для управления кластерами из контейнеров. Система динамическая, она реагирует на события в режиме реального времени и позволяет поднять сервис, который будет просто работать без танцев с бубном и масштабироваться по запросу. Гибко, быстро, экономически эффективно — именно то, что нужно разработчикам!
В практике администрирования Kubernetes используется понятие подов (pods). Каждый под — это группа объединенных общей задачей контейнеров (к примеру, на том же Docker), которые могут быть и микросервисом, и массивным приложением, разнесенным на несколько параллельно работающих машин. Kubernetes призван решать проблемы с эффективным распределением выполнения контейнеров по узлам кластера в зависимости от изменения нагрузки и текущей потребности в сервисах. Иными словами, перед нами — система гибкого управления инфраструктурой контейнеризации с возможностью балансировки нагрузки.
Давай перечислим основные технические задачи, которые можно решить с помощью Kubernetes:
Сегодня K8s стал неким стандартом для современных DevOps-сред как в больших компаниях, так и среди стартапов. Он активно используется в облачных сервисах вроде AWS, Microsoft Azure или Google Cloud.
По своей сути Kubernetes представляет собой один из стратегических компонентов всего DevOps-процесса, именно поэтому атаки на него всегда были и остаются актуальными. Ведь, взломав эту систему, хакер получит доступ ко всем нодам и контейнерам, запущенным внутри K8s, а это уже прямой путь и к компрометации или утечке конфиденциальных данных.
Самое печальное, что в сети до сих пор полно публичных K8s-серверов, доступ к которым можно получить из интернета. Как? Широко известен, например, замечательный сервис Shodan, который позволяет искать уязвимые версии ПО, доступные из интернета и «готовые к атаке». От таких незакрытых уязвимостей в свое время пострадали десятки тысяч публичных баз MongoDB. Если ты захочешь проверить, как работает Shodan на практике, это можно сделать при помощи поискового скрипта, выложенного на GitHub.
Как мы выяснили чуть раньше, K8s имеет довольно сложную архитектуру и использует в своем составе множество компонентов. Потому векторы и типы атак на эту систему тоже разнятся. Итак, общая площадь атак включает в себя:
Master Node — главный мастер-сервер, который управляет всем кластером рабочих узлов (подов) и развертыванием модулей на этих узлах;
Worker Node — рабочие серверы, на которых запускают контейнеры приложений и другие компоненты Kubernetes, к примеру такие, как K8s-агенты и прокси-серверы;
Pods — это неделимая элементарная единица развертывания и адресации в Kubernetes. Под имеет собственный IP-адрес и может содержать один или несколько контейнеров;
Services — сетевые службы, обеспечивающие обмен данными внутри кластера, балансировку, репликацию, обрабатывающие запросы и так далее;
System Components — ключевые системные компоненты, которые используются для управления кластером Kubernetes: сервер API, Kubelet и другие.
Как и в любой сложной системе, придуманной людьми, в инфраструктуре кластера K8s имеются типичные проблемы безопасности, с которыми часто сталкиваются системные администраторы. Ниже я перечислю самые известные из них.
Increased Attack Surface (увеличенная площадь атаки). Проблема основывается на том, что каждый контейнер может иметь различную поверхность атаки и собственные уникальные уязвимости, которые используются хакерами для дальнейшего взлома. К примеру, могут использоваться уязвимости для Docker или системы авторизации AWS.
Container compromise (компрометация контейнера). Суть атаки кроется в использовании неверной конфигурации (security misconfiguration) для всех контейнеров кластера, которые косвенным образом способствуют компрометации или же включают в себя уязвимости приложений. К компрометациям контейнера относятся манипуляции внутренней коммутацией, управлением процессами или доступом к файловой системе.
Unauthorized connections between pods (несанкционированные соединения между подами внутри единого кластера). Скомпрометированные контейнеры могут соединяться с другими контейнерами на том же или на других хостах, чтобы запустить какую-либо атаку. Несмотря на то что фильтрация на уровне L3 (ACL-листы) обеспечивается сетевым оборудованием согласно настроенным правилам, некоторые неавторизованные обращения могут быть обнаружены только с помощью фильтрации на седьмом уровне модели OSI.
Любой прикладной и системный софт имеет ряд критических уязвимостей, и K8s не исключение. Наличие подобных багов ставит под угрозу весь кластер, от запущенных контейнеров в целом до конкретных данных, хранящихся внутри БД на каком-либо отдельном поде.
По статистике, собранной из реестра уязвимостей NIST, больше всего критических ошибок было обнаружено в 2018 году — восемь штук, и четыре уязвимости найдены уже в текущем году. Ниже я расскажу о самых громких багах, наделавших много шуму среди разработчиков, которые использовали Kubernetes.
Первая уязвимость получила номер CVE-2019-5736. Об этом баге, обнаруженном в текущем году, мы уже писали на страницах нашего журнала. Он позволяет вредоносному контейнеру перезаписать исполняемый файл runC на хост-системе, при этом никакого взаимодействия с пользователем не требуется. В результате подобной атаки злоумышленник может получить root-доступ к хосту и возможность исполнять на нем произвольный код. В феврале 2019 года эксплоит для CVE-2019-5736 был опубликован на GitHub.
Еще один баг, выявленный в марте 2019 года, имеет идентификатор CVE-2019-11246. Он позволяет атакующему доставлять файлы из пода на компьютер оператора или модифицировать их с помощью подмены tar binary, используя обычную внутреннюю команду kubectl cp.
Другой прошлогодний баг — CVE-2018-1002105 связан с эскалацией привилегий. Он позволяет атакующему повысить привилегии в кластере и получить к нему доступ из-за логической ошибки обработки API-вызовов. Эксперты по безопасности оценили уязвимость в 9,8 балла по шкале CVSS, поскольку брешь не требует предварительной аутентификации и проста в эксплуатации. Несанкционированный доступ открывается после отправки специфического запроса к API-серверу Kubernetes. Все уязвимые сборки Kubernetes некорректно обрабатывают вредоносный запрос, позволяя обратиться к бэкенду с использованием учетных данных TLS, прописанных в настройках API-сервера. Через несколько дней после обнаружения проблемы PoC-эксплоит был опубликован на GitHub. Позже выпустили патч, закрывающий эту уязвимость.
Вот общий сценарий действий хакеров при использовании уязвимости CVE-2018-1002105.
Еще один громкий кейс, связанный с K8s, имел место в 2018 году. Речь идет о взломе аккаунта всем известной компании Tesla в облаке Amazon Web Services. Как позже выяснили эксперты, учетные данные в одном из подов Kubernetes открыли доступ к среде AWS Tesla, которая содержала корзину Amazon S3. В ней, в свою очередь, хранились конфиденциальные данные, в том числе телеметрия. Однако вместо кражи этих данных хакеры начали майнить криптовалюту на одном из подов Tesla.
Хороший и доступный каждому админу бенчмарк проверки безопасности K8s — набор CIS Kubernetes Benchmark, который можно бесплатно забрать с официального сайта CIS или GitHub-репозитория. Набор включает список рекомендуемых требований безопасности, чек-лист проверки и скрипты для автоматического анализа текущих конфигураций K8s.
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее
1 год5380 р. |
1 месяц720 р. |
Я уже участник «Xakep.ru»
Читайте также
Последние новости
2009-2024 © Все права защищены.
This website - is fan-site, not an official Huawei website. The Huawei logo is a trademark of Huawei Technologies. Other trademarks are the property of their respective owners.
|