Kubernetes по умолчанию содержит настройки, не соответствующие современным стандартам безопасности. По данным BI.ZONE EDR, в компаниях, использующих Kubernetes, подавляющее большинство кластеров содержат критические мисконфигурации — от открытого API-сервера до незашифрованных данных в etcd и уязвимых настроек kubelet. Именно на эти слабые места нацелены атаки, например с применением вредоноса Kinsing: он использует уязвимые поды как ресурсы для майнинга или как точки распространения внутри системы. 

В этой статье — гид по харденингу Kubernetes, основанный на рекомендациях CIS и реальном опыте реагирования на инциденты. 

Введение

Kubernetes — одна из самых востребованных платформ для оркестрации контейнеров. Однако по умолчанию она содержит небезопасные настройки, что создает критические риски для защищенности данных. Это подтверждают и данные телеметрии BI.ZONE TDR: Kubernetes используют около 40% компаний, при этом подавляющее большинство кластеров содержат мисконфигурации в настройках. Среди наиболее частых проблем — открытый API-сервер, неограниченный доступ к kubelet, эксплуатация уязвимостей в контейнерах и отсутствие изоляции между ворклоадами.

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

Цель этой статьи — систематизировать меры по харденингу кластера Kubernetes. Также мы на примерах покажем, каким образом решение BI.ZONE EDR выявляет мисконфигурации, отклонения от рекомендуемых настроек и параметры запуска компонентов 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 и другие.

Как BI.ZONE EDR усиливает безопасность Kubernetes

Сервисы BI.ZONE, такие как BI.ZONE TDR и BI.ZONE EDR, объединяют рекомендации CIS с проверенными на практике методами обеспечения безопасности. Защитные меры охватывают все ключевые уровни: от управляющих компонентов и узлов до приложений, сетевой инфраструктуры и процедур обновления. Такой подход позволяет выстроить устойчивую к угрозам архитектуру Kubernetes, соответствующую требованиям современных стандартов безопасности. 

BI.ZONE EDR поддерживает интеграцию с основными контейнерными рантаймами (такими как Docker, containerd, LXC, Podman) и обеспечивает мониторинг непосредственно на уровне контейнеров. Это позволяет отслеживать выполнение команд, подозрительную активность внутри подов, а также контролировать использование чувствительных данных и системных сокетов. Таким образом решение не только выявляет потенциально опасные настройки, но и комплексно защищает управляющий слой, рабочие узлы и приложения Kubernetes.

Обзор архитектуры и компонентов Kubernetes

Чтобы эффективно защищать Kubernetes-кластер, важно понимать, из каких компонентов он состоит и какую роль играет каждый компонент. Kubernetes имеет модульную архитектуру, которая разделена на два слоя: control plane (управляющий слой) и data plane (рабочие узлы, или worker nodes, и приложения).

Компоненты управляющего слоя (control plane)

• Kube-apiserver — центральная точка взаимодействия со всеми компонентами и пользователями. Обрабатывает REST-запросы, обеспечивает аутентификацию, авторизацию и валидацию объектов.

• Kube-scheduler — отвечает за выбор оптимального узла для запуска нового пода на основе доступных ресурсов, ограничений и политик.

• Kube-controller-manager — запускает контроллеры, поддерживающие состояние кластера (например, контроллеры ReplicaSet, Node, namespace).

• Etcd — распределенное хранилище ключей-значений, в котором содержится все состояние кластера, включая конфигурации, секреты, статус подов.

• Cloud-controller-manager (необязательный) — обеспечивает интеграцию с облачными провайдерами (например, создание LoadBalancer в AWS/GCP).

Компоненты рабочих узлов (worker nodes)

• 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

Kube-apiserver представляет собой центральную точку взаимодействия со всеми компонентами и пользователями Kubernetes. Все операции управления кластером — включая команды kubectl, действия контроллеров и обращения от внешних интеграций — проходят через API-сервер. Он выполняет функции аутентификации, авторизации, валидации запросов и их маршрутизации к соответствующим компонентам управляющего слоя. Компрометация kube-apiserver эквивалентна получению полного административного доступа к кластеру, включая возможность управления всеми ресурсами, подами и секретами.

Рекомендации по защите компонента

Отключите анонимный доступ к 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

Компонент kube-controller-manager отвечает за запуск множества контроллеров, реализующих автоматическое управление состоянием объектов в кластере (например, NodeController, ReplicationController, ServiceAccountController). Он выполняется от имени администратора Kubernetes и при неправильной настройке может стать вектором эскалации привилегий.

Рекомендации по защите компонента

Минимизируйте права и разделяйте ответственность

Убедитесь, что параметр --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 отвечает за принятие решений о размещении подов на узлах, исходя из ресурсов, ограничений и политик планирования. Хотя он не взаимодействует напрямую с пользователями, компрометация kube-scheduler может позволить злоумышленнику повлиять на размещение рабочих нагрузок, обойти политики и нарушить изоляцию.

Рекомендации по защите компонента 

Ограничьте права доступа

Убедитесь, что 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

Компонент etcd — это распределенное хранилище, в котором Kubernetes сохраняет состояние кластера, включая конфигурации, определения объектов и чувствительные данные (secrets, ConfigMaps, токены ServiceAccount и т. п.). Компрометация etcd эквивалентна полному захвату управления кластером.

Рекомендации по защите компонента

Настройте 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

Kubelet — агент, работающий на каждом узле кластера. Он обеспечивает запуск и мониторинг подов, взаимодействует с контейнерным рантаймом и предоставляет API-интерфейс для управления состоянием подов. Неправильная конфигурация kubelet может позволить злоумышленнику получить доступ к исполняемым контейнерам, выполнять команды или собирать чувствительные данные.

Рекомендации по защите компонента

Отключите анонимный доступ к 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

Kube-proxy — это сетевой компонент, работающий на каждом узле кластера. Он отвечает за маршрутизацию трафика к сервисам Kubernetes, управляя правилами iptables и IPVS. Хотя kube-proxy выполняет вспомогательные функции, его неправильная настройка может привести к сетевым уязвимостям и некорректной маршрутизации трафика.

Рекомендация по защите компонента

Ограничьте интерфейс привязки (--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 — не разовая задача, а непрерывный цикл улучшений, сочетающий технические меры защиты с продуманными организационными процедурами. Только такой системный подход позволяет выстроить действительно устойчивую к угрозам инфраструктуру.