Kubernetes давно зарекомендовал себя как одна из ведущих систем оркестрации контейнеров, обеспечивая удобство и масштабируемость для разработки и эксплуатации приложений. Однако с ростом популярности этой платформы увеличивается и интерес злоумышленников к её уязвимостям. Одним из важных аспектов безопасности является понимание того, как атакующие сохраняют и расширяют своё присутствие внутри Kubernetes-кластера после первоначального получения доступа. Понимание этих методов открывает новые горизонты для проактивной защиты и минимизации рисков. Начальные механизмы проникновения зачастую связаны с получением учётных данных администратора Kubernetes, например, через скомпрометированные ноутбуки сотрудников.
Злоумышленники, попавшие на устройство с административным доступом, сталкиваются с необходимостью максимально быстро закрепиться в инфраструктуре, чтобы сохранить контроль до возвращения законного пользователя и избежать обнаружения. Одним из первых шагов для злоумышленника становится получение root-доступа к одному из узлов кластера. Kubernetes предоставляет встроенный инструмент kubectl debug, который резко упрощает запуск отладочной сессии с высоким уровнем привилегий на выбранном узле. Использование профиля sysadmin при запуске debug-сессии гарантирует максимальный уровень доступа, что делает его особенно привлекательным для атакующего. После получения shell-доступа на узле возникает задача загрузить и запустить дополнительные инструменты для исследования и контроля среды.
Операционные системы узлов часто имеют повышенные меры безопасности - файловые системы могут быть смонтированы только для чтения или с запрещённым выполнением бинарников. Однако возможность запуска контейнеров остаётся открытой, что позволяет злоумышленникам обойти подобные ограничения. Контейнеры выполняются с помощью container runtime - чаще всего containerd или CRI-O, и, находясь непосредственно на узле, злоумышленник может взаимодействовать с этими инструментами напрямую, минуя Kubernetes API. Примером такой техники служит создание отдельного namespace для containerd с помощью утилиты ctr. В отличие от Kubernetes namespaces и Linux namespaces, containerd namespaces представляют собой собственную изоляцию внутри контейнерного рантайма.
Создавая незаметный namespace с нейтральным названием, атакующий усложняет для сисадминов выявление следов проникновения. После этого с помощью ctr можно загрузить подозрительный образ из ненадёжных источников, например, docker.io/sysnetmon/systemd_net_mon:latest, и запустить его контейнер с правами, дающими полный доступ к файловой системе и сетевым интерфейсам хоста. Другой техникой, позволяющей запускать контейнеры без взаимодействия с API сервером Kubernetes, является использование статических манифестов. Клети kubelet считывают описания статических подов из определённых директорий на узле.
Особенностью злоумышленнической стратегии становится использование недопустимых имён пространств, чтобы такие поды не регистрировались в API-сервере и не отображались в списках, обычных для администраторов. Это создаёт дополнительный уровень скрытности. Несмотря на получение физического доступа и запуск контейнеров, сохранять удалённый контроль для злоумышленника - ключевая задача. Парковка таймера на момент, когда законный администратор снова вернётся за ноутбук, ставит под угрозу всю операцию. Среди решений популярностью пользуются легковесные и трудно детектируемые средства удалённого доступа, такие как Tailscale - VPN на базе WireGuard с минимальными требованиями и высокой скрытностью.
Разработчики атак используют статически скомпилированные исполняемые файлы, которые могут быть переименованы в обманчиво безобидные имена, например, systemd_net_mon_server и systemd_net_mon_client. Запуск Tailscale-сервера и клиента обеспечивает зашифрованное соединение по стандартному HTTPS-порту 443, что часто не вызывает подозрений в корпоративных сетях. При этом серверная часть Tailscale содержит встроенный SSH-сервер, что позволяет злоумышленнику подключаться к контейнеру напрямую без запуска дополнительных сервисов SSH, которые легко могут привлекать внимание системы обнаружения угроз. Для более устойчивого присутствия злоумышленники стремятся получить долговременные учётные данные, позволяющие работать с кластером без непосредственного использования API Kubernetes, что могло бы заметить систему аудита. Обращение к Kubelet API подразумевает работу на узлах по порту 10250/TCP, для которого зачастую отсутствует аудит.
Создание необходимых сертификатов для пользователя через Certificate Signing Request (CSR) API - одна из эффективных тактик. Используя утилиту, например,uisteanas, атакующий может генерировать kubeconfig-файлы для любых учётных записей, включая системные аккаунты с повышенными правами. Ключевым моментом является выбор пользователей, уже обладающих необходимыми RBAC-привилегиями, что снижает вероятность обнаружения и предотвращает необходимость привязки новых ролей. CSR API интересен злоумышленникам по нескольким причинам: отсутствие обязательного аудита при правильной настройке, невозможность отзыва сгенерированных через него сертификатов без масштабной ротации всего центра сертификации, а также длительные сроки действия таких сертификатов, доходящие до нескольких лет. Кроме того, возможность создавать учётные записи для системных аккаунтов усложняет выявление зловредных действий даже там, где аудит ведётся.
Если использование CSR API ограничено, злоумышленники могут прибегнуть к Token Request API. Хотя его назначение - выдача токенов сервисных аккаунтов, атакующий, обладающий соответствующими правами, может генерировать токены, которые сложно отозвать без удаления сервисного аккаунта. Эти токены хоть и имеют ограниченный срок действия, могут варьироваться от суток до года, что всё равно предоставляет долговременные возможности для сохранения доступа. Предотвращение подобных сценариев взлома начинается с ограничений внешнего доступа. Оставлять Kubernetes API открыт для доступа из интернета без существенной фильтрации - прямая дорога к компрометации.
Многие managed Kubernetes-сервисы помогают ограничивать диапазон IP или требуют VPN, но эти меры зачастую не включены по умолчанию. Концепция наименьших привилегий также остаётся краеугольным камнем. Административные учётные записи с полномочиями cluster-admin создают слишком широкий диапазон для злоумышленников. Рэгламентирование прав, отказ от избыточных полномочий и минимизация использования функций вроде Node Debugging, CSR и Token Request API в повседневном управлении - всё это помогает снизить риски. Обнаружение таких атак требует качественного аудита с централизованным хранением логов Kubernetes и узлов.
Установка агентского ПО безопасности, способного анализировать нетипичный трафик и процессы на узлах, поможет выявлять, например, подозрительную работу Tailscale или запуск посторонних контейнеров. Знание нормального состояния кластеров и процессов на узлах позволяет оперативно замечать аномалии - незнакомые процессы или контейнеры с подозрительными именами, которые не соответствуют стандартам дистрибутива или политики провайдера. Подводя итог, сценарии сохранения доступа злоумышленников в Kubernetes комбинируют использование встроенных инструментов платформы с креативным применением функций контейнерного рантайма и сторонних средств удалённого контроля. Глубокое понимание данных методов открывает путь к построению более тревожно устойчивой инфраструктуры и минимизации последствий при инцидентах компрометации. Чем тщательнее администраторы подходят к настройке прав, мониторингу и сегментации доступа, тем выше шансы обезопасить Kubernetes-кластеры от опасных и скрытных атак.
.
