Содержание статьи
- О Kubernetes в двух словах
- Обзор основных векторов атак на Kubernetes
- Проблемы безопасности K8s
- Примеры критических багов
- Усиливаем безопасность Kubernetes
- Рекомендуемые шаги для усиления безопасности перед развертыванием K8s-кластера
- Утилиты для аудита безопасности
- Легитимность используемых образов
- Безопасность эксплуатации
- Безопасность сетевого взаимодействия
- Коммерческие решения для безопасности Kubernetes
- Дополнительные утилиты для усиления безопасности Kubernetes
- Заключение
В прошлой статье я рассказал о том, как проверить текущий уровень защищенности очень популярной в DevOps-среде системы контейнеризации Docker и как повысить этот самый уровень. Сегодня мы продолжим изучать вопросы безопасности DevOps-инфраструктуры, и у нас под прицелом система контейнерной оркестрации на базе Kubernetes. Мы разберем основные векторы атак, изучим нашумевшие уязвимости, а также соберем набор инструментов, необходимый для обеспечения безопасности кластера на Kubernetes. Приступим!
О Kubernetes в двух словах
Я думаю, каждый, кто хотя бы однажды сталкивался с миром DevOps, имеет общее представление о том, что такое Kubernetes. Если кратко, то это довольно популярная система контейнерной оркестрации (правда, к музыке и оркестрам она не имеет ни малейшего отношения). На чем основывается популярность Kubernetes и чем он так хорош?
Kubernetes, или, сокращенно, K8s, — система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими, реализованная на базе открытого программного обеспечения. Проект был основан в 2014 году. Оригинальная версия некогда разрабатывалась в недрах самой Google для внутренних нужд корпорации, но впоследствии была передана под управление опенсорсному фонду Cloud Native Computing Foundation, откуда и попала в широкие массы.
Изначально K8s задумывалась как система-менеджер для управления кластерами из контейнеров. Система динамическая, она реагирует на события в режиме реального времени и позволяет поднять сервис, который будет просто работать без танцев с бубном и масштабироваться по запросу. Гибко, быстро, экономически эффективно — именно то, что нужно разработчикам!
![Архитектура системы контейнерной оркестрации K8s](https://xakep.ru/wp-content/uploads/2019/08/235580/1.jpg)
В практике администрирования Kubernetes используется понятие подов (pods). Каждый под — это группа объединенных общей задачей контейнеров (к примеру, на том же Docker), которые могут быть и микросервисом, и массивным приложением, разнесенным на несколько параллельно работающих машин. Kubernetes призван решать проблемы с эффективным распределением выполнения контейнеров по узлам кластера в зависимости от изменения нагрузки и текущей потребности в сервисах. Иными словами, перед нами — система гибкого управления инфраструктурой контейнеризации с возможностью балансировки нагрузки.
Давай перечислим основные технические задачи, которые можно решить с помощью Kubernetes:
- запуск большого числа контейнеров Docker или Rocket на большом количестве хостов;
- мониторинг состояния run-time-среды и своевременное реагирование на изменения;
- управление запущенными контейнерами, обеспечение их совместного размещения и межконтейнерной репликации;
- масштабирование и балансировка большого количества хостов в пределах кластера.
Сегодня K8s стал неким стандартом для современных DevOps-сред как в больших компаниях, так и среди стартапов. Он активно используется в облачных сервисах вроде AWS, Microsoft Azure или Google Cloud.
По своей сути Kubernetes представляет собой один из стратегических компонентов всего DevOps-процесса, именно поэтому атаки на него всегда были и остаются актуальными. Ведь, взломав эту систему, хакер получит доступ ко всем нодам и контейнерам, запущенным внутри K8s, а это уже прямой путь и к компрометации или утечке конфиденциальных данных.
Самое печальное, что в сети до сих пор полно публичных K8s-серверов, доступ к которым можно получить из интернета. Как? Широко известен, например, замечательный сервис Shodan, который позволяет искать уязвимые версии ПО, доступные из интернета и «готовые к атаке». От таких незакрытых уязвимостей в свое время пострадали десятки тысяч публичных баз MongoDB. Если ты захочешь проверить, как работает Shodan на практике, это можно сделать при помощи поискового скрипта, выложенного на GitHub.
![Результат поиска публичных сервисов K8s с помощью Shodan](https://xakep.ru/wp-content/uploads/2019/08/235580/8.jpg)
Обзор основных векторов атак на Kubernetes
Как мы выяснили чуть раньше, K8s имеет довольно сложную архитектуру и использует в своем составе множество компонентов. Потому векторы и типы атак на эту систему тоже разнятся. Итак, общая площадь атак включает в себя:
-
Master Node — главный мастер-сервер, который управляет всем кластером рабочих узлов (подов) и развертыванием модулей на этих узлах;
-
Worker Node — рабочие серверы, на которых запускают контейнеры приложений и другие компоненты Kubernetes, к примеру такие, как K8s-агенты и прокси-серверы;
-
Pods — это неделимая элементарная единица развертывания и адресации в Kubernetes. Под имеет собственный IP-адрес и может содержать один или несколько контейнеров;
-
Services — сетевые службы, обеспечивающие обмен данными внутри кластера, балансировку, репликацию, обрабатывающие запросы и так далее;
-
System Components — ключевые системные компоненты, которые используются для управления кластером Kubernetes: сервер API, Kubelet и другие.
![Типовые векторы атак на K8s](https://xakep.ru/wp-content/uploads/2019/08/235580/2.jpg)
Проблемы безопасности K8s
Как и в любой сложной системе, придуманной людьми, в инфраструктуре кластера K8s имеются типичные проблемы безопасности, с которыми часто сталкиваются системные администраторы. Ниже я перечислю самые известные из них.
- Explosion of East-West Traffic, или атака «Взрыв трафика Восток — Запад». Суть этой атаки заключается в том, что контейнеры могут быть динамически развернуты в нескольких независимых друг от друга облаках, что значительно увеличивает трафик обмена данными внутри логического кластера. Это похоже на перегон поездов по железной дороге, и именно поэтому данный вид атак получил название «С востока на запад». Удаленное расположение контейнеров может использоваться злоумышленниками, например, для реализации DDoS-атак.
![Схематичное описание атаки Explosion of East-West Traffic](https://xakep.ru/wp-content/uploads/2019/08/235580/10.jpg)
-
Increased Attack Surface (увеличенная площадь атаки). Проблема основывается на том, что каждый контейнер может иметь различную поверхность атаки и собственные уникальные уязвимости, которые используются хакерами для дальнейшего взлома. К примеру, могут использоваться уязвимости для Docker или системы авторизации AWS.
-
Container compromise (компрометация контейнера). Суть атаки кроется в использовании неверной конфигурации (security misconfiguration) для всех контейнеров кластера, которые косвенным образом способствуют компрометации или же включают в себя уязвимости приложений. К компрометациям контейнера относятся манипуляции внутренней коммутацией, управлением процессами или доступом к файловой системе.
-
Unauthorized connections between pods (несанкционированные соединения между подами внутри единого кластера). Скомпрометированные контейнеры могут соединяться с другими контейнерами на том же или на других хостах, чтобы запустить какую-либо атаку. Несмотря на то что фильтрация на уровне L3 (ACL-листы) обеспечивается сетевым оборудованием согласно настроенным правилам, некоторые неавторизованные обращения могут быть обнаружены только с помощью фильтрации на седьмом уровне модели OSI.
![Некоторые нашумевшие кейсы, связанные с безопасностью K8s](https://xakep.ru/wp-content/uploads/2019/08/235580/7.jpg)
Примеры критических багов
Любой прикладной и системный софт имеет ряд критических уязвимостей, и K8s не исключение. Наличие подобных багов ставит под угрозу весь кластер, от запущенных контейнеров в целом до конкретных данных, хранящихся внутри БД на каком-либо отдельном поде.
По статистике, собранной из реестра уязвимостей NIST, больше всего критических ошибок было обнаружено в 2018 году — восемь штук, и четыре уязвимости найдены уже в текущем году. Ниже я расскажу о самых громких багах, наделавших много шуму среди разработчиков, которые использовали Kubernetes.
![Статистика уязвимостей K8s из реестра NIST](https://xakep.ru/wp-content/uploads/2019/08/235580/4.jpg)
Первая уязвимость получила номер CVE-2019-5736. Об этом баге, обнаруженном в текущем году, мы уже писали на страницах нашего журнала. Он позволяет вредоносному контейнеру перезаписать исполняемый файл runC на хост-системе, при этом никакого взаимодействия с пользователем не требуется. В результате подобной атаки злоумышленник может получить root-доступ к хосту и возможность исполнять на нем произвольный код. В феврале 2019 года эксплоит для CVE-2019-5736 был опубликован на GitHub.
Еще один баг, выявленный в марте 2019 года, имеет идентификатор CVE-2019-11246. Он позволяет атакующему доставлять файлы из пода на компьютер оператора или модифицировать их с помощью подмены tar binary, используя обычную внутреннюю команду kubectl cp.
![Схематичное описание уязвимости CVE-2019-11246](https://xakep.ru/wp-content/uploads/2019/08/235580/5.jpg)
Другой прошлогодний баг — CVE-2018-1002105 связан с эскалацией привилегий. Он позволяет атакующему повысить привилегии в кластере и получить к нему доступ из-за логической ошибки обработки API-вызовов. Эксперты по безопасности оценили уязвимость в 9,8 балла по шкале CVSS, поскольку брешь не требует предварительной аутентификации и проста в эксплуатации. Несанкционированный доступ открывается после отправки специфического запроса к API-серверу Kubernetes. Все уязвимые сборки Kubernetes некорректно обрабатывают вредоносный запрос, позволяя обратиться к бэкенду с использованием учетных данных TLS, прописанных в настройках API-сервера. Через несколько дней после обнаружения проблемы PoC-эксплоит был опубликован на GitHub. Позже выпустили патч, закрывающий эту уязвимость.
![Схематичное описание уязвимости CVE-2018-1002105](https://xakep.ru/wp-content/uploads/2019/08/235580/6.jpg)
Вот общий сценарий действий хакеров при использовании уязвимости CVE-2018-1002105.
- Определение локации в ИТ-ландшафте, где запущен K8s.
- Эксплуатация известных уязвимостей облачных провайдеров.
- Запуск команд внутри контейнера.
- Доступ к файловой системе node.
- Разведка во внутренней сети, горизонтальное расширение и закрепление внутри взломанных систем.
Еще один громкий кейс, связанный с K8s, имел место в 2018 году. Речь идет о взломе аккаунта всем известной компании Tesla в облаке Amazon Web Services. Как позже выяснили эксперты, учетные данные в одном из подов Kubernetes открыли доступ к среде AWS Tesla, которая содержала корзину Amazon S3. В ней, в свою очередь, хранились конфиденциальные данные, в том числе телеметрия. Однако вместо кражи этих данных хакеры начали майнить криптовалюту на одном из подов Tesla.
![Пошаговый сценарий взлома AWS облака Tesla c целью майнинга](https://xakep.ru/wp-content/uploads/2019/08/235580/9.jpg)
![](/wp-content/themes/engine/img/info-icon.jpg)
INFO
Хороший и доступный каждому админу бенчмарк проверки безопасности K8s — набор CIS Kubernetes Benchmark, который можно бесплатно забрать с официального сайта CIS или GitHub-репозитория. Набор включает список рекомендуемых требований безопасности, чек-лист проверки и скрипты для автоматического анализа текущих конфигураций K8s.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»