Обзор инструментов для оценки безопасности кластера Kubernetes: kube-bench и kube-hunter25.08.2021 11:17

Популярность Kubernetes растет, порог входа снижается, но вопросам безопасности порой оказывают недостаточное внимание. В этой статье разберём работу двух Open Source-утилит для аудита безопасности кластера от известных экспертов этой области — Aqua Security.

kube-bench

kube-bench — приложение на Go, которое проверяет, соответствует ли кластер Kubernetes рекомендациям CIS Kubernetes Benchmark. Проект имеет богатую историю (появился на GitHub еще в 2017-м году) и явный спрос у сообщества (почти 4000 звёзд).

Что за CIS (Center for Internet Security)? Это некоммерческая организация, которая занимается вопросами кибербезопасности, основываясь на обратной связи от сообщества. CIS Benchmark, в свою очередь, — это сформулированный список рекомендаций по настройке окружения для защиты от кибератак. Данные рекомендации включают в себя поиск слишком широких прав доступа к файлам конфигурации и небезопасных параметров компонентов кластера, незащищенных учётных записей, проверку сетевых и общих политик.

Kube-bench поддерживает версии Kubernetes от 1.15 и выше, а также совместима с платформами GKE, EKS и OCP (версии 3.10 и 4.1).

Рассмотрим работу последней (на момент написания статьи) версии утилиты — v0.6.3 — на стендовом кластере Kubernetes 1.19.

Запуск и настройка

Проще всего запустить kube-bench, скачав готовый исполняемый файл и передав ему конфигурацию в качестве аргумента запуска:

curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.3/kube-bench_0.6.3_linux_amd
4.tar.gz -o kube-bench_0.6.3_linux_amd64.tar.gz && \
tar -xvf kube-bench_0.6.3_linux_amd64.tar.gz && \
./kube-bench --config-dir `pwd`/cfg --config `pwd`/cfg/config.yaml

Также можно запустить утилиту в Docker-контейнере:

docker run --rm --pid=host -v /etc:/etc:ro /var/lib/etcd:/var/lib/etcd:ro -v /var/lib/kubelet/config.yaml:/var/lib/kubelet/config.yaml:ro  -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v $HOME/.kube:/.kube -e KUBECONFIG=/.kube/config -it aquasec/kube-bench:latest run

В принципе, есть и готовый манифест для запуска в кластере. Но для того, чтобы проверка, запущенная данным манифестом, была валидной, необходимо запускать её в двух экземплярах: одну на master-узле, вторую — на worker-узле, и с разным наборов входных параметров. Кроме того, предложенный разработчиками манифест выполняет только малую часть тестов.

Утилита работает «из коробки», настраивать ее необходимости нет. Чтобы отключить ненужные, на ваш взгляд, тесты или дописать свои, можно изменить конфигурационные файлы в каталоге ./cfg/. В нашем случае, согласно документации, при запуске в кластере Kubernetes 1.19 использовалась конфигурация CIS 1.20.

Вывод результатов и рекомендации

Отчет разделен на пять тематических блоков с говорящими за себя названиями:

Master Node Security Configuration;
Etcd Node Configuration;
Control Plane Configuration;
Worker Node Security Configuration;
Kubernetes Policies.

Вывод программы — богатый, по каждому типу проверки есть объяснение. Единственное, что не является очевидным в данном выводе — пометки Automated/Manual около каждого теста. Простого объяснения найти не удалось. В документации есть пометка If the test is Manual, this always generates WARN (because the user has to run it manually), но ясности она не добавляет, потому что на скриншоте явно видно прохождение тестов с типом Manual.

Вот для примера вывод Worker Node Security Configuration:

Как видим, было проведено 23 теста. Чуть подробнее разберем пункты 4.1.5 и 4.1.6, для чего обратимся к соответствующему конфигурационному файлу. Согласно ему, kube-bench проверил права на файл kubelet.conf и определил, что они выставлены корректно, а сам файл принадлежит пользователю root. В данном случае, перепроверив вручную, убедимся, что kube-bench не ошибся:

Отдельного внимания стоит тот факт, что утилита некорректно работает с symlink«ами, из-за чего (если вы их используете) может возвращать ложноотрицательные результаты.

А теперь, пожалуй, главное: следом за тестами идут рекомендации о том, как устранить ту или иную проблему.

По всем тестам, которые завершились результатом [FAIL] или [WARN], предложен алгоритм необходимых действий.

Например, для устранения уязвимости 4.2.6 предлагается при запуске kubelet передавать ему флаг --protect-kernel-defaults=true. При этом важно понимать, что после активации этого флага kubelet больше не сможет вносить изменения в sysctl, а это с высокой долей вероятности приведёт к его неработоспособности до дальнейшего ручного вмешательства и устранения несоответствий.

Другой пример:

Предлагается отключить анонимный доступ к kube-apiserver, но это сделает невозможным работу liveness и readiness checks у pod«а apiserver. В результате чего он начнет падать с некоторой периодичностью.

Еще один пример — предлагается указать --kubelet-certificate-authority, который тоже сделает неработоспособным часть функционала…

Также некоторые тесты по какой-то причине показали некорректный результат. Например, я получил Failed на эту проверку:

Хотя, если посмотреть в конфигурацию, там установлено нужное значение:

Резюме

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

А также не совсем понятно, что делать с рекомендациями, поскольку следование им может сломать кластер, а игнорирование — генерирует в душе чувство неудовлетворенности и опасение за безопасность кластера.

kube-hunter

Инструмент kube-hunter написан на Python и также предназначен для поиска уязвимостей в кластере Kubernetes. От предыдущей утилиты отличается тем, что нацелен на оценку защиты кластера с точки зрения «атакующего». Тоже имеет достаточно богатую историю: развивается с 2018 года и получил 3000+ звёзд на GitHub.

Запускать и рассматривать мы его будем на том же кластере Kubernetes версии 1.19.

Установка

Инсталляция сводится к простой команде:

pip3 install kube-hunter

Также можно запустить с помощью Docker:

docker run -it --rm --network host aquasec/kube-hunter

Выбор режима проверки

Пользователю предлагается на выбор 3 варианта проверок:

Remote scanning — проверка конкретного IP-адреса или DNS-имени. По сути, это попытка найти уязвимости в кластере за каким-либо адресом;
Interface scanning — сканирование интерфейсов. Функционал тот же, что и в первом варианте, но поиск уязвимостей проводится на всех локальных интерфейсах;
Network scanning — тот же поиск, но с указанием сети.

Также отдельно стоит упомянуть про режим Active Hunting, при котором приложение, используя найденные уязвимости, вносит изменения в кластер. Например, пытается записать что-то в etcd, выполнить «uname -a» в случайном pod«е и прочитать /etc/shadow из pod«а, куда примонтирован каталог /var/log. Полный список «активных охотников» в составе утилиты:

Запуск

В целях обзорной презентации будем запускать пассивное сканирование непосредственно с мастер-узла: сначала через публичный адрес, а потом через локальный.

Проверка Remote scanning запускается командой kube-hunter --remote

— в данном режиме утилита работает с одним целевым IP-адресом.Как можно видеть ниже, ни один из компонентов кластера недоступен извне:

При сканировании локального интерфейса ситуация уже иная: kube-hunter обнаружил API Server, etcd, Kubelet API и даже нашел одну некритичную уязвимость (смог определить версию кластера Kubernetes).

Смоделируем уязвимость

Чтобы продемонстрировать пример уязвимости, я разрешу взаимодействие с etcd по HTTP, поменяв конфигурацию в /etc/kubernetes/manifests/etcd.yaml. Результат не заставил себя долго ждать: kube-hunter обнаружил незащищённый endpoint для работы с etcd и предупредил о том, что потенциальный недоброжелатель может использовать уязвимость для получения доступа к etcd.

Резюме

kube-hunter — неплохая утилита для пентеста кластера Kubernetes. Она легко устанавливается и запускается, даёт представление о том, как ваш кластер выглядит глазами злоумышленника.

Правда, к сожалению, в выводе команд не удалось найти советов по устранению найденных уязвимостей. Например, нам могут (и весьма справедливо!) сообщить, что Api Server not patched for CVE-2019–11247, но что с этим делать?…

Наконец, утилита очень агрессивно сканирует сети, на что могут реагировать netscan-детекторы провайдеров

Вывод

Обе рассмотренные утилиты в первом приближении выглядят достаточно «взрослыми» и удобными в работе, дают общее представление о защищенности компонентов кластера. Пусть не без изъянов, но, на мой взгляд, это неплохая отправная точка для тех, кто интересуется вопросами безопасности кластера.

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

P.S. Kubescape как бонус

Ранее в этом месяце мы рассказывали, что Агентство по национальной безопасности и Агентство по кибербезопасности и защите инфраструктуры США опубликовали совместный отчет — «Руководство по усилению безопасности Kubernetes» (Kubernetes Hardening Guidance).

Это событие получило большой интерес со стороны Kubernetes-сообщества. Вплоть до того, что уже стал доступен первый инструмент для проверки K8s-инсталляций на соответствие требованиям, описанным в этом документе. Он называется Kubescape и уже успел за свое недолгое время существования собрать ~1600 GitHub-звёзд. Вполне вероятно, что его захотите попробовать и вы:

P.P. S.

Читайте также в нашем блоге: