Как проверить безопасность кластера Kubernetes с помощью BI.ZONE EDR
Kubernetes — одна из самых востребованных платформ для оркестрации контейнеров. Однако по умолчанию она содержит небезопасные настройки, что создает критические риски для защищенности данных. Это подтверждают и данные телеметрии BI.ZONE TDR: Kubernetes используют около 40% компаний, при этом подавляющее большинство кластеров содержат мисконфигурации в настройках. Среди наиболее частых проблем — открытый API‑сервер, неограниченный доступ к kubelet, эксплуатация уязвимостей в контейнерах и отсутствие изоляции между ворклоадами.
Такие уязвимости делают Kubernetes одним из приоритетных векторов для атак, особенно в средах с высокой степенью автоматизации. Учитывая, что на платформе часто размещаются критические приложения и данные, обеспечить ее безопасность становится задачей первостепенной важности.
Цель этой статьи — систематизировать меры по харденингу
Практика показывает, что многие инциденты в продакшен‑кластерах происходят не из‑за сложных атак нулевого дня, а в результате ошибок конфигурации, отсутствия минимальных мер защиты и игнорирования рекомендуемых практик безопасности. При этом после развертывания многие базовые настройки кластера не обеспечивают достаточную защиту.
Один из наиболее известных примеров эксплуатации уязвимых кластеров Kubernetes — использование вредоносного ПО Kinsing. Оно нацелено на контейнерные среды: активно сканирует интернет в поисках открытых Kubernetes API‑серверов и Docker‑демонов, а затем разворачивает майнер криптовалюты. После проникновения в кластер Kinsing использует возможности контейнера для побега в хост‑систему, загружает дополнительные скрипты и закрепляется в системе. Этот пример демонстрирует, как даже одна неправильно сконфигурированная точка входа может привести к полной компрометации инфраструктуры.
В ответ на растущие угрозы были разработаны специализированные рекомендации, такие как CIS Kubernetes Benchmark — документ Центра интернет‑безопасности (Center for Internet Security, CIS), который описывает меры по защите компонентов кластера: от API‑сервера и kubelet до etcd и узлов. Также существуют рекомендации Агентства национальной безопасности США (National Security Agency, NSA), практические инструменты kube‑bench, kube‑hunter, Trivy и другие.
Чтобы эффективно защищать Kubernetes‑кластер, важно понимать, из каких компонентов он состоит и какую роль играет каждый компонент. Kubernetes имеет модульную архитектуру, которая разделена на два слоя: control plane (управляющий слой) и data plane (рабочие узлы, или worker nodes, и приложения).
- Kube‑apiserver — центральная точка взаимодействия со всеми компонентами и пользователями. Обрабатывает REST‑запросы, обеспечивает аутентификацию, авторизацию и валидацию объектов.
- Kube‑scheduler — отвечает за выбор оптимального узла для запуска нового пода на основе доступных ресурсов, ограничений и политик.
- Kube‑controller‑manager — запускает контроллеры, поддерживающие состояние кластера (например, контроллеры ReplicaSet, Node, namespace).
- Etcd — распределенное хранилище ключей‑значений, в котором содержится все состояние кластера, включая конфигурации, секреты, статус подов.
- Cloud-controller-manager (необязательный) — обеспечивает интеграцию с облачными провайдерами (например, создание LoadBalancer в AWS/GCP).
- Kubelet — агент, запущенный на каждом узле. Следит за состоянием подов, взаимодействует с API‑сервером, запускает контейнеры через CRI.
- Kube‑proxy — реализует сетевую проксировку и правила NAT для доступа к сервисам Kubernetes.
- Контейнерный рантайм (container runtime) — компонент, запускающий контейнеры (например, containerd, CRI‑O или Docker в старых версиях).
- Namespace — логическое разделение ресурсов в кластере.
- RBAC — система управления доступом на основе ролей.
- Secrets и ConfigMaps — объекты для хранения чувствительных данных и конфигураций.
- Network policies — правила контроля сетевого взаимодействия между подами.
- Admission-контроллеры — плагины, выполняющие дополнительные проверки и модификации объектов перед сохранением в etcd.
Каждая точка взаимодействия компонентов — потенциальная поверхность атаки. Поэтому знание компонентов и принципов их взаимодействия необходимо не только для эксплуатации платформы, но и для выстраивания многоуровневой модели безопасности.
Компоненты control plane выступают центральным координационным механизмом кластера. Они отвечают:
- за принятие решений по размещению и масштабированию рабочих нагрузок,
- контроль состояния компонентов,
- обработку пользовательских запросов,
- реализацию политик управления.
Компрометация управляющего слоя предоставляет атакующему полный доступ к управлению кластером, включая возможность изменять конфигурации, запускать произвольные контейнеры и получать доступ к конфиденциальным данным. Поэтому при развертывании и эксплуатации кластера важно контролировать безопасность control plane.
Рассмотрим подробнее его ключевые компоненты, рекомендации по их защите, а также способы детектирования небезопасных настроек с помощью BI.ZONE EDR.
Kube-apiserver представляет собой центральную точку взаимодействия со всеми компонентами и пользователями Kubernetes. Все операции управления кластером — включая команды kubectl, действия контроллеров и обращения от внешних интеграций — проходят через API‑сервер. Он выполняет функции аутентификации, авторизации, валидации запросов и их маршрутизации к соответствующим компонентам управляющего слоя. Компрометация kube‑apiserver эквивалентна получению полного административного доступа к кластеру, включая возможность управления всеми ресурсами, подами и секретами.
/etc/kubernetes/manifests/kube‑apiserver.yaml. С помощью мониторинга BI.ZONE EDR можно получить настройки из этого файла и сделать вывод о наличии мисконфигураций.Отключите анонимный доступ к API‑серверу
По умолчанию kube‑apiserver может разрешать анонимные запросы, если опцию не отключили. Это представляет серьезную угрозу, особенно при открытом API‑интерфейсе. Убедитесь, что флаг --anonymous-auth=false установлен, чтобы все входящие запросы требовали аутентификации. Если параметр отличается от значения false, то можно сделать вывод о возможности анонимного доступа к API, что потенциально ведет к компрометации кластера.
Пример таких срабатываний:
Используйте режим RBAC и принцип наименьших привилегий
Убедитесь, что в конфигурации kube‑apiserver включен режим авторизации RBAC, указав параметр --authorization-mode=RBAC. Это позволяет централизованно управлять доступом к ресурсам Kubernetes на основе ролей и принципа минимально необходимого доступа. С помощью мониторинга BI.ZONE EDR можно проверить разрешенные режимы авторизации, анализируя параметры запуска kube‑apiserver. Отсутствие RBAC в списке значений --authorization-mode может указывать на наличие менее безопасных схем авторизации (например, AlwaysAllow, которая установлена по умолчанию), что потенциально приводит к эскалации привилегий и компрометации компонентов кластера. Помимо отсутствия RBAC, в этом же параметре необходимо проверять и ограничение запросов внутри ноды, для этого выставив параметр node в той же строке --authorization-mode. Важно убедиться, что в параметре --authorization-mode отсутствует значение AlwaysAllow.
С помощью BI.ZONE EDR можно детектировать кластеры, в которых разрешены запросы откуда угодно и без разграничения RBAC:
Используйте TLS и шифрование
Все компоненты управляющего слоя должны использовать TLS для защиты сетевого взаимодействия. Убедитесь, что API‑сервер (kube‑apiserver), kube‑controller‑manager, планировщик (kube‑scheduler) и другие компоненты используют корректно настроенные TLS‑сертификаты, выданные доверенным центром сертификации (CA). Критически важно проверять параметры --tls-cert-file, --tls-private-key-file и --client-ca-file в манифесте kube‑apiserver, чтобы исключить использование самоподписанных и устаревших сертификатов.
Кроме того, рекомендуется включить проверку клиентских сертификатов, указав флаг --client-ca-file, и ограничить доступ к API по сертификатам с соответствующей авторизацией.
Средства мониторинга BI.ZONE EDR помогают автоматически анализировать конфигурации и выявлять отсутствующие сертификаты. Иначе такие мисконфигурации могут привести к MitM‑атакам или несанкционированному доступу к API:
Включите аудит и логирование
Включение аудита API‑сервера — ключевая мера для отслеживания действий в кластере. Убедитесь, что указаны параметры --audit-log-path и --audit-policy-file в манифесте kube‑apiserver. Файл политики (audit‑policy.yaml) должен быть настроен для записи привилегированных действий. Логи аудита следует хранить в защищенном месте с ограниченным доступом и ретеншен‑периодом, соответствующим требованиям безопасности внутри компании. Рекомендуется реализовать доставку логов в SIEM‑систему для последующего анализа, корреляции событий и выявления аномалий.
Средствами BI.ZONE EDR можно выявить отключенное логирование Kubernetes:
Настройте безопасную конфигурацию admission‑контроллеров
Admission‑контроллеры — это встроенные плагины в kube‑apiserver, которые выполняют валидацию, модификацию или отклонение создаваемых объектов до их сохранения. Правильная настройка набора admission‑контроллеров — важный шаг в защите кластера от ошибочных или небезопасных конфигураций. В соответствии с известными политиками безопасности Kubernetes рекомендуется использовать для конфигурации следующие параметры в файле манифеста kube‑apiserver:
--enable-admission-plugins=<value>— включает необходимые контроллеры.--disable-admission-plugins=<value>— отключает те, которые считаются устаревшими или небезопасными.
Плагины, которые рекомендуется включать (--enable-admission-plugins):
- NamespaceLifecycle — контролирует жизненный цикл пространств имен (namespace), предотвращает удаление системных пространств;
- NodeRestriction — ограничивает действия kubelet, защищает объекты node и pod;
- ServiceAccount — автоматически добавляет ServiceAccount в создаваемые поды;
- PodSecurity — применяет политики безопасности к подам на основе уровней доверия (privileged, baseline, restricted);
- AlwaysPullImages — проверяет подлинность и новизну контейнерных образов.
Плагины, которые рекомендуется отключать (--disable-admission-plugins):
- AlwaysAdmit — небезопасный контроллер, допускающий все изменения без проверок;
- PodSecurityPolicy — официально удален из Kubernetes и больше не поддерживается, заменен на PodSecurity.
Убедитесь, что все вышеуказанные флаги прописаны в конфигурационном файле kube‑apiserver. Регулярный аудит этих настроек важен для поддержания безопасного состояния кластера.
BI.ZONE EDR автоматически проверяет включенные и отключенные admission‑контроллеры в рамках контроля безопасных настроек и поиска мисконфигураций:
Обеспечьте шифрование секретов в etcd
Kubernetes поддерживает механизм шифрования данных в etcd на уровне API‑сервера. Для этого необходимо создать специальный encryption‑configuration‑файл и указать путь к нему через флаг --encryption-provider-config в манифесте kube‑apiserver.
Поддерживаются следующие типы шифрования (указаны в порядке предпочтения использования):
- aescbc (рекомендуется),
- secretbox,
- aesgcm,
- identity (без шифрования, использовать только как fallback).
BI.ZONE EDR позволяет выявлять хосты управляющего слоя Kubernetes, на которых не настроено шифрование данных в etcd:
Компонент kube-controller-manager отвечает за запуск множества контроллеров, реализующих автоматическое управление состоянием объектов в кластере (например, NodeController, ReplicationController, ServiceAccountController). Он выполняется от имени администратора Kubernetes и при неправильной настройке может стать вектором эскалации привилегий.
/etc/kubernetes/manifests/kube-controller-manager.yaml. С помощью мониторинга BI.ZONE EDR можно получить настройки из этого файла и сделать вывод о наличии мисконфигураций.Минимизируйте права и разделяйте ответственность
Убедитесь, что параметр --use-service-account-credentials=true установлен. Это позволяет каждому контроллеру выполнять действия от имени собственного ServiceAccount с ограниченными правами вместо использования общих полномочий контроллер‑менеджера:
Ограничьте доступ к kubeconfig-файлу
Файл, указанный в параметре --kubeconfig, должен:
- быть доступен только пользователю root (права 0600);
- содержать токен с ограниченными правами доступа, достаточными для выполнения задач конкретного контроллера.
Проводите аудит и проверку флагов
Регулярно проверяйте наличие и корректность следующих флагов:
--root-ca-file,--service-account-private-key-file.
Эти флаги обеспечивают надежную аутентификацию, контроль полномочий и минимизацию потенциального ущерба в случае компрометации одного из контроллеров:
Все параметры должны соответствовать рекомендациям специалистов по кибербезопасности и быть предметом регулярного аудита средствами конфигурационного контроля. Такой аудит можно выполнить с помощью BI.ZONE EDR, который детектирует мисконфигурации в настройках kube‑controller‑manager и может подсветить администраторам отсутствие настроек, повышающих безопасность кластера.
Компонент kube‑scheduler отвечает за принятие решений о размещении подов на узлах, исходя из ресурсов, ограничений и политик планирования. Хотя он не взаимодействует напрямую с пользователями, компрометация kube‑scheduler может позволить злоумышленнику повлиять на размещение рабочих нагрузок, обойти политики и нарушить изоляцию.
/etc/kubernetes/manifests/kube-scheduler.yaml. С помощью мониторинга BI.ZONE EDR можно получить настройки из этого файла и сделать вывод о наличии мисконфигураций.Ограничьте права доступа
Убедитесь, что kube‑scheduler запускается с собственным kubeconfig‑файлом, предоставляющим минимально необходимые разрешения. Файл должен быть доступен только процессу планировщика (права доступа — 0600, владелец — root).
Отключите профилирование через HTTP (--profiling=false)
По умолчанию kube‑scheduler включает HTTP‑интерфейс для профилирования (pprof), что может привести к утечке чувствительной информации. Установите --profiling=false, чтобы отключить доступ к /debug/pprof и снизить возможную поверхность атаки:
Ограничьте интерфейс привязки (--bind-address=127.0.0.1)
По умолчанию некоторые компоненты Kubernetes (в том числе kube‑scheduler) могут слушать на всех интерфейсах (0.0.0.0), что открывает их для внешнего доступа. Установите --bind-address=127.0.0.1, чтобы ограничить доступ только с локального хоста:
Даже при отсутствии прямого взаимодействия с внешними компонентами kube‑scheduler является важной частью цепочки принятия решений и должен быть надежно изолирован и ограничен в правах. BI.ZONE EDR помогает в поиске мисконфигураций компонента kube‑scheduler и позволяет администраторам не допустить его компрометации.
Компонент etcd — это распределенное хранилище, в котором Kubernetes сохраняет состояние кластера, включая конфигурации, определения объектов и чувствительные данные (secrets, ConfigMaps, токены ServiceAccount и т. п.). Компрометация etcd эквивалентна полному захвату управления кластером.
/etc/kubernetes/manifests/etcd.yaml. С помощью мониторинга BI.ZONE EDR можно получить настройки из этого файла и сделать вывод о наличии мисконфигураций.Настройте TLS и аутентификацию клиентов
Включите шифрование TLS и проверку сертификатов на стороне клиента:
--cert-file,--key-file— серверный сертификат и ключ;--client-cert-auth=true— требование клиентской аутентификации;--trusted-ca-file— доверенный центр сертификации для валидации клиентов.
Это обеспечит защищенное и проверенное взаимодействие между компонентами кластера (например, API‑сервером) и etcd. Также с помощью BI.ZONE EDR можно детектировать etcd, не использующие TLS:
Обеспечьте изоляцию на уровне сети
Убедитесь, что etcd доступен только с узлов control plane. Используйте сетевые политики, сетевые экраны и HostNetwork‑ограничения для исключения доступа с других хостов. Открытый доступ к порту etcd (по умолчанию по порту 2379) категорически недопустим.
Регулярно проводите резервное копирование и тест восстановления
Настройте автоматические бэкапы etcd с верификацией восстановления. Проверяйте, что копии доступны и актуальны. Используйте etcdctl snapshot save/restore или встроенные средства облачных платформ.
Узлы Kubernetes представляют собой физические или виртуальные хосты, на которых размещаются и исполняются поды. Являясь частью data plane, они обеспечивают выполнение приложений, доступ к сетевым ресурсам и файловым системам. Компрометация узла может привести к получению доступа к чувствительным данным (например, токенам ServiceAccount), хранилищу контейнеров, логам, а также к возможности горизонтального перемещения в пределах кластера или атаки на управляющие компоненты. Поэтому защита узлов — критически важная часть общей стратегии безопасности Kubernetes.
Kubelet — агент, работающий на каждом узле кластера. Он обеспечивает запуск и мониторинг подов, взаимодействует с контейнерным рантаймом и предоставляет API‑интерфейс для управления состоянием подов. Неправильная конфигурация kubelet может позволить злоумышленнику получить доступ к исполняемым контейнерам, выполнять команды или собирать чувствительные данные.
/var/lib/kubelet/kubelet-config.yaml. С помощью мониторинга BI.ZONE EDR можно получить настройки из этого файла и сделать вывод о наличии мисконфигураций.Отключите анонимный доступ к API kubelet (--anonymous-auth=false)
По умолчанию kubelet может обрабатывать анонимные запросы, что представляет серьезную угрозу, особенно при наличии открытого сетевого доступа к kubelet API. Убедитесь, что параметр --anonymous-auth=false установлен, чтобы все входящие запросы требовали аутентификации.
В рамках мониторинга с использованием BI.ZONE EDR можно проанализировать содержимое конфигурационного файла kubelet. Если для параметра anonymous‑auth не указано значение false, это указывает на потенциально небезопасную настройку, позволяющую получить доступ к API kubelet без токенов или сертификатов. Такое отклонение может сигнализировать о возможности выполнения команд в подах или доступа к чувствительной информации:
Отключите незащищенный read‑only‑порт (--read-only-port=0)
По умолчанию kubelet запускает HTTP‑сервер на порте 10255, который предоставляет неаутентифицированный доступ к метрикам, информации о подах и статусу узла. Это создает серьезную угрозу безопасности, особенно если порт доступен из внешней сети. Убедитесь, что для флага --read-only-port указано значение 0, полностью отключая этот интерфейс. Это исключает возможность обхода механизмов аутентификации и доступа к внутренней информации узла.
В рамках проверки соответствия с помощью BI.ZONE EDR можно проанализировать флаги запуска kubelet, доступные в unit‑файле systemd или в конфигурации kubelet. Если для read-only-port указано значение, отличное от 0, это сигнализирует о потенциальной возможности для злоумышленника получить информацию о состоянии кластера без прохождения аутентификации:
Включите webhook-авторизацию (--authorization-mode=Webhook)
Флаг --authorization-mode определяет, как kubelet принимает решения о доступе к своим API. Значение AlwaysAllow полностью отключает авторизацию и допускает любые запросы, включая выполнение команд внутри контейнеров (/exec) и доступ к их содержимому (/run, /pods). Согласно практикам безопасности использование AlwaysAllow категорически не допускается. Рекомендуется установить --authorization-mode=Webhook, чтобы kubelet передавал все запросы на проверку на API‑сервер, где применяется централизованная политика RBAC. BI.ZONE EDR можно использовать для анализа параметров запуска kubelet:
Используйте TLS и проверку клиентских сертификатов (--tls-cert-file, --client-ca-file)
Для защиты API‑интерфейса kubelet необходимо использовать TLS‑сертификаты и настроить валидацию клиентских соединений. Убедитесь, что заданы следующие флаги:
--tls-cert-fileи--tls-private-key-file— путь к серверному сертификату и приватному ключу, используемым kubelet для шифрования соединений;--client-ca-file— путь к корневому сертификату, с помощью которого kubelet будет проверять клиентские TLS‑сертификаты.
Отсутствие этих параметров может привести к незащищенному доступу и MitM‑атакам. Настройка двустороннего TLS‑аутентифицированного канала гарантирует, что только доверенные субъекты смогут взаимодействовать с API kubelet. BI.ZONE EDR позволяет анализировать параметры запуска kubelet, включая флаги TLS. Если отсутствует --client-ca-file либо любой другой сертификат, система формирует оповещение. Это позволяет своевременно выявлять риски, связанные с неправильной или отсутствующей конфигурацией TLS:
Kube-proxy — это сетевой компонент, работающий на каждом узле кластера. Он отвечает за маршрутизацию трафика к сервисам Kubernetes, управляя правилами iptables и IPVS. Хотя kube‑proxy выполняет вспомогательные функции, его неправильная настройка может привести к сетевым уязвимостям и некорректной маршрутизации трафика.
/var/lib/kube-proxy/config.*. С помощью мониторинга BI.ZONE EDR можно получить настройки из этого файла и сделать вывод о наличии мисконфигураций.Ограничьте интерфейс привязки (--bind-address)
Настройте kube‑proxy на прослушивание только 127.0.0.1 или внутреннего интерфейса, исключая доступ из внешних сетей, если это возможно в рамках вашей архитектуры. Если требуется доступ с других узлов или из внешних систем (например, Prometheus) — безопаснее указать внутренний IP‑адрес интерфейса, по которому разрешен доступ: --bind-address=10.0.2.15 (или другой IP из приватной сети, используемой внутри организации или VPC). При этом необходимо убедиться, что доступ к порту ограничен на уровне iptables, сетевых экранов, security groups или сетевых политик. Использование --bind-address=0.0.0.0 считается мисконфигурацией, если в этом нет крайней необходимости, так как это открывает порт на всех интерфейсах, включая публичные:
Рантайм (containerd, CRI‑O, Docker) отвечает за фактический запуск контейнеров. Компрометация контейнерного рантайма дает атакующему полный контроль над процессами внутри подов.
Ограничьте сокеты
Сокет containerd (/run/containerd/containerd.sock) не должен быть доступен пользователям или процессам. Любой процесс, получивший доступ к сокету, фактически может управлять контейнерами на узле от имени root. Даже если злоумышленник получает доступ к сокету, в том числе без root‑доступа на узле, он может запустить «привилегированный» контейнер, монтировать файловую систему хоста и получить root‑доступ, что дает возможность атак типа «побег из контейнера».
Используйте актуальные версии и настройте изоляцию
Всегда обновляйтесь, а для ограничения доступа контейнеров к системным ресурсам настройте:
- seccomp — фильтрация опасных системных вызовов (например,
ptrace,mount,reboot); - AppArmor/SELinux — контроль доступа к файлам хоста, сокетам и устройствам;
- SELinux (в режиме
enforcing) — разграничение доступа на уровне ядра с использованием меток.
Все это снижает риск побега из контейнера и ограничивает возможный ущерб при компрометации.
Не используйте Docker в production
Разработчики Kubernetes официально отказались от поддержки Docker как рантайма (начиная с v1.24, релиз от 03.05.2022). Лучше использовать containerd или CRI‑O.
Харденинг Kubernetes требует комплексного подхода, когда защита охватывает все компоненты системы: control plane, worker nodes, сетевую инфраструктуру, контейнеры и приложения.
Хотя внедрение общепринятых практик и рекомендаций обеспечивает базовый уровень защиты, этого недостаточно для полноценной безопасности. Kubernetes по умолчанию содержит небезопасные настройки, что требует дополнительных мер:
- постоянного аудита конфигураций и устранения ошибок с помощью инструментов, например BI.ZONE EDR;
- строгого контроля доступа и минимизации привилегий;
- тщательной сегментации сети;
- мониторинга runtime‑активности контейнеров.
Не менее важны организационные аспекты: грамотное управление изменениями, регулярное обучение сотрудников, автоматизация процессов обновления и реагирования.
Безопасность Kubernetes — не разовая задача, а непрерывный цикл улучшений, сочетающий технические меры защиты с продуманными организационными процедурами. Только такой системный подход позволяет выстроить действительно устойчивую к угрозам инфраструктуру.