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

Для начала давайте посмотрим, какие преимущества дает использование сканеров безопасности k8s. Прежде всего, сканер должен выявлять неправильные конфигурации и уязвимости в кластере, контейнерах и подсистемах. Кроме этого, он должен предоставлять решения для исправления неправильной конфигурации и устранения уязвимостей. Ну и неплохо было бы дать представление о текущем состоянии кластера, позволяющее избежать сбоев в работе кластера, выявляя проблемы на ранней стадии.

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

В качестве подопытных кроликов у нас будут выступать MicroK8s v1.32.1 revision 7665, развернутый на Ubuntu 24.04 и Minikube v1.34.0, развернутый на другой машине также под Ubuntu 24.04. Оба развертывания имеют настройки ОС и k8s по умолчанию, никакие дополнительные харденинги не проводились.

Kube Bench

Kube Bench — это один из наиболее известных сканеров безопасности с открытым исходным кодом, который проверяет, соответствуют ли ваши настройки эталону безопасности CIS (Center for Internet Security).

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

Развернуть это решение довольно просто. Необходимо создать файл манифеста job.yaml Полный текст этого файла мы здесь приводить не будем, чтобы не увеличивать без надобности размер статьи. Манифест содержит описание Job, который создает под, содержащий контейнер на базе образа docker.io/aquasec/kube‑bench:v0.10.0. К этому поду монтируются в режиме Read‑Only различные каталоги хостовой машины: /var/lib/cni, /var/lib/etcd, /var/lib/kubelet и другие. После чего собственно и начинается проверка подмонтированных ресурсов.

Для проверки кластера нужно выполнить Job:

kubectl apply -f job.yaml

Далее следим за состоянием подов и дожидаемся состояния Completed. Правда, у меня при запуске он некоторое время выдавал ошибки загрузки образа, но в итоге все было успешно выполнено:

kubectl get pods

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

kubectl logs kube-bench-9fzcz

Последние пять символов генерирует сам k8s при запуске Job, и у вас они будут отличаться.

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

Для Microk8s получили следующее:

Для Minikube:

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

Checkov

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

Для запуска проверки здесь мы также запускаем Job:

kubectl apply -f https://raw.githubusercontent.com/bridgecrewio/checkov/main/kubernetes/checkov-job.yaml

Как видно, Job запускается в Production Ready конфигурации, то есть в собственном пространстве имен и с необходимыми настройками доступа.

Выполним get jobs, чтобы узнать, когда Job завершит свою работу:

kubectl get jobs -n checkov

Результат также смотрим через лог:

kubectl logs job/checkov -n checkov

Здесь мы видим в отчете перечисление всех проверок и их результаты:

И на Microk8s, и на Minikube Job без проблем запустился и выдал достаточно подробные отчеты.

Kubescan

И наш третий участник — это Kube Scan. Его также можно установить в новый кластер, после чего он просканирует рабочие нагрузки, которые в данный момент запущены в вашем кластере, и покажет оценку риска и подробную информацию о нем. Оценка риска варьируется от 0 до 10, 0 означает отсутствие риска, а 10 — высокий риск.

Работа с этим сканером осуществляется через веб‑интерфейс, который становится доступным после запуска Deployment и сервиса, описанных в YAML файле.

Запустим YAML:

kubectl apply -f https://raw.githubusercontent.com/octarinesec/kube-scan/master/kube-scan.yaml

Далее пробросим порт для доступа к веб-интерфейсу. Если порт 8080 у вас уже занят, укажите другой.

kubectl port-forward --namespace kube-scan svc/kube-scan-ui 8080:80

Как видно, здесь у нас тоже все готово к использованию в промышленной среде.

Для того, чтобы получить доступ к результатам сканирования, обратимся к веб-интерфейсу по указанному ранее порту:

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

Заключение

В этой статье мы рассмотрели лишь несколько сканеров, работающих непосредственно в k8s без использования дополнительных приложений и компонентов. По этой причине в статью не попали такие достаточно известные сканеры, как Trivy, Snyk, Kubeaudit и многие другие.

Также мы не пытались сравнивать результаты сканирования Microk8s и Minikube, так как для того, чтобы сделать вывод, кто из них (не)дырявее нужно детально изучать отчеты сканеров и смотреть, какие проверки выполнялись и какой у них был результат.

Целью статьи было показать инструменты, которые легко можно встроить в процессы DevSecOps для проведения регулярных проверок безопасности.

В заключение напомню об открытых уроках по DevSecOps, которые пройдут в Otus в феврале, и на которые можно записаться бесплатно:

• 6 февраля: «Безопасная разработка Python». Узнаете о наиболее эффективных пол, какие подходы к безопасной разработке на Python наиболее эффективны, а также Навыки внедрения этих подходов в повседневную практику для повышения защиты проектов. Регистрация

• 20 февраля: «Введение в DevSecOps». Узнаете, что такое DevSecOps и какие инструменты помогут сделать ваши проекты более надёжными и безопасными с самых ранних стадий разработки. Регистрация