С ростом популярности Kubernetes все больше компаний стремятся использовать его для облегчения управления контейнеризованными приложениями. Вместе с этой тенденцией наблюдается рост числа незащищенных (или неправильно сконфигурированных) кластеров, имеющих прямой доступ в интернет. Это создает большие риски для безопасности, поскольку такие кластеры могут быть обнаружены с использованием поисковых сайтов и атакованы злоумышленниками.
В статье рассмотрим базовые концепции мониторинга и обеспечения безопасности кластера Kubernetes, поговорим о распространенных векторах атак, а также разберем способы их обнаружения и метрики, которые в этом помогут.
В основе этого материала лежит статья "# The Beginner's Guide to Securing Kubernetes", которая была переработана и дополнена.
Основы Kubernetes
Чтобы разобраться в том, как защищать кластер, пробежимся по основам Kubernetes.
Важный фан-факт: cокращение "K8s" образуется путем замены восьми букв между "K" и "s" числом "8" в слове Kubernetes
Образ контейнера — это архив, который содержит в себе операционную систему, приложения и библиотеки, необходимые для запуска ПО в изолированной среде.
Контейнер — запущенный в среде запуска контейнеров (например, Docker Engine) образ контейнера.
Pod — в K8s представляет собой основную единицу развертывания, которая состоит из одного или нескольких контейнеров, работающих на одной ноде. Контейнеры внутри pod’ов совместно используют ресурсы и локальные сети, обеспечивая возможность взаимодействия друг с другом.
Ноды (узлы) — виртуальные или физические машины в составе кластера k8s, которые используются для выполнения контейнеров. Они делятся на два типа:
− Worker — нода, на которой запускаются Pod'ы;
− Control Plane — нода, осуществляющая управление Worker-нодами и Pod'ами в кластере (состоит из компонентов kube-apiserver, etcd, kube-scheduler, controller-manager), а также состоянием кластера.
Верхнеуровневая архитектура Kubernetes
Три важных компонента, которые есть на каждой Worker-ноде кластера для управления Pod'ами:
Kubelet взаимодействует с контейнерами и самой нодой. Отвечает за выделение ресурсов для каждого контейнера. Kubelet запускает Pod с контейнером внутри и убеждается, что тот запустился и успешно работает.
KubeProxy обеспечивает связь между нодами кластера, перенаправляет и балансирует входящий/исходящий трафик.
Среда запуска контейнеров (Runtime) — ПО, предназначенное для запуска контейнеров (Containerd, CRI-O).
Подобно Worker-ноде, Control-Plane-нода содержит четыре компонента, отвечающих за основные действия в кластере:
API Server — сердце K8s, принимающее запросы от различных элементов кластера на создание/обновление/удаление объектов.
Scheduler отвечает за выбор ноды, на которой будет развернут Pod.
Control Manager следит за состоянием кластера (отвечая за то, чтобы фактическое состояние кластера соответствовало желаемому), отслеживает различные ошибки Pod'ов и запросы scheduler'а на развертывание новых Pod'ов.
etcd — «память» кластера K8s. Это база данных, которая хранит в себе информацию о конфигурации кластера.
Пользователи могут взаимодействовать с API кластера с помощью инструмента kubectl. Он позволяет управлять ресурсами, проверять состояние кластера, развертывать приложения и выполнять множество других задач.
Концепция безопасности кластера K8s
При построении безопасности кластера K8s стоит учитывать следующие подходы:
− ролевое управление доступом (RBAC) — разграничение прав пользователей и процессов в соответствии с принципом наименьших привилегий, регулярная проверка выданных прав;
− контроль трафика — применение сетевых политик позволит обеспечить управление трафиком между компонентами, разрешив только необходимые связи;
− управление секретами — контроль доступа к секретам, их регулярная ротация, а также разграничение по окружениям, интеграция с системами управления секретами;
− настройки параметров безопасности при создании Pod'ов — различные параметры, которые позволяют обеспечить безопасность на уровне конкретного Pod'а, тем самым предотвращая возможные попытки эскалации привилегий.
В рамках статьи мы обсудим такие направления безопасности, как:
Защита нод кластера;
Защита оркестратора (Control Plane);
Безопасность используемых образов;
Безопасность манифестов;
Защита контейнеров в runtime.
Защита Control Plane
Control Plane — осуществляет управление состоянием кластера, предоставляет API-интерфейс для взаимодействия и отвечает за следующие ключевые функции:
управление состоянием (делает все возможное, чтобы нынешнее состояние кластера соответствовало желаемому, то есть заданному пользователем);
планирование (выбор рабочей ноды для размещения Pod’ов в соответствии с доступными ресурсами и политикой развертывания);
обработка запросов API (обрабатывает все запросы к кластеру и взаимодействия с другими компонентами);
управление конфигурацией кластера, его настройками и параметрами различных ресурсов (deployment, service, configmap и др.);
отвечает за создание событий и уведомления (настройка Control Plane позволяет отслеживать различные события, облегчая мониторинг за его состоянием и безопасностью).
Защиту Control Plane можно разделить на пять главных направлений:
Безопасность передачи данных;
Аутентификация;
Авторизация;
Admission Control;
Аудит.
Безопасность передачи данных
Весь трафик Control Plane шифруется с помощью TLS на первом, не localhost-интерфейсе (порт 6443). Для повышения безопасности следует использовать сертификат, выпущенный корпоративным УЦ.
Сертификат УЦ кластера должен быть добавлен в клиентский конфигурационный файл (~/.kube/config).
Аутентификация запросов
После того как соединение с кластером установлено, HTTP-запрос переходит к шагу аутентификации. Аутентификация запросов в K8s осуществляется с помощью различных модулей (сертификат, пароль, токен, bootstrap-токен, JWT).
При настройке API-сервера можно указать несколько аутентификационных модулей, которые будут последовательно проводить проверку запроса до тех пор, пока она не пройдет успешно или завершится с ошибкой. Убедитесь, что для каждого пользователя используется только один метод аутентификации.
Авторизация
Далее наступает процесс авторизации запроса, в котором содержится множество атрибутов, но наиболее интересными с точки зрения обеспечения безопасности будут:
имя пользователя / сервисного аккаунта;
действие;
целевой объект.
Для просмотра атрибутов запросов, которые выполнялись в кластере, предварительно необходимо настроить Audit Policy (в kube-apiserver.yaml).
В Kubernetes используются различные модули авторизации запросов (AlwaysAllow, ABAC, Node, RBAC и WebHook), если ни один из модулей не смог подтвердить запрос, то он отклоняется. По умолчанию используются модули авторизации Node и RBAC, однако в процессе эксплуатации они могут быть изменены. Рекомендуется убедиться, что в настройках kube-apiserver отсутствует параметр «--authorization-mode=AlwaysAllow».
Admission Control
Admission-контроллеры — это программные модули в составе Kubernetes, которые могут изменять или отклонять запрос на основании различных правил. Они используют информацию об объекте, который планируется создать или изменить. Admission-контроллер перехватывает запросы, направленные на создание/изменение/удаление объектов, не ограничивая простое чтение информации об объекте.
В Kubernetes используются Admission-контроллеры следующих типов: Mutating, Validation и Validation and Mutating. Они могут быть как встроенными, так и внешними (Kyverno, OPA GateKeeper). Validation-контроллеры отвечают за проверку манифеста на наличие в нем определенных параметров (например, namespaceExists, отвечающий за проверку, что заданный namespace существует). Так же можно сказать и о Pod Security Admission, который отвечает за применение Pod Security Standard (о нем мы поговорим ниже). Mutating-контроллер может изменять параметры запроса (например, подставляя StorageClass, определенный в кластере по умолчанию). Соответственно, комбинация Validation and Mutating выполняет проверку и изменение параметров запроса.
При использовании нескольких контроллеров если один из них отклонит запрос, то дальнейшая проверка выполняться не будет.
Используйте Admission-контроллеры (встроенные или внешние) для проверки и управления запросами к API-серверу перед их обработкой. По умолчанию используется только NodeRestriction-модуль (в зависимости от версии K8s, набор включенных контроллеров может отличаться), в соответствии с CIS Kubernetes Benchmark рекомендуется дополнительно настроить модули EventRateLimit, AlwaysPullImages, ServiceAccount, Namespacelifecycle.
Финальным шагом проверяется соответствие запроса особенностям API запрашиваемого объекта (схемам), после которого он попадает в базу.
Аудит
Используя внутренний аудит, можно получить важную информацию о событиях в кластере (создание, изменение или удаление ресурсов, а также доступ к API Kubernetes). События генерируются пользователями, приложениями, которые используют Kubernetes API, и действиями Control-plane-ноды. Kubernetes поддерживает передачу событий как в файл, так и в сторонние системы. Это позволяет обеспечить централизованный сбор и анализ событий аудита для дальнейшего использования и реагирования на инциденты.
По умолчанию аудит в кластере K8s отключен, после развертывания кластера рекомендуется выполнить базовую настройку kube-apiserver (указать файл политики аудита с помощью флага –audit-policy-file=, определить место для хранения журналов флагом –audit-log-path=). Далее необходимо определить события, которые требуется собирать (например, запросы на создание/удаление объектов), настроить отправку в SIEM-систему, а также подготовить правила корреляции.
Для изучения механики работы правил аудита и удобной работы с ними рекомендуем ознакомиться с «Генератором политик аудита», созданного командой «Штурвала».
Теперь перейдем к обеспечению безопасности Pod'ов и RBAC API.
Безопасность Pod’ов
До введения Pod Security Standard (PSS) использовался Admission-контроллер Pod Security Policy (PSP), который позволял контролировать важные с точки зрения безопасности характеристики Pod'ов. Начиная с v.1.21, PSP считается устаревшим и был удален в версии v1.25.
На данный момент PSS обеспечивает гибкую настройку политик безопасности и имеет три режима.
1. Privileged — без ограничений. В данном режиме не ограничиваются возможности повышения привилегий. Pod, для которого применяется такая политика, может обойти типичные механизмы изоляции контейнера.
2. Baseline — режим с минимальными ограничениями. Позволяет выполнить только минимальную настройку Pod'а. Подходит для некритичных приложений. В проверку входят параметры, связанные с настройками HostProcess, Privileged Containers, определен список разрешенных Capabilities и т.д.).
3. Restricted — максимальные ограничения. Применяет к Pod'ам различные ограничения в соответствии с лучшими мировыми практиками. Может использоваться для критичных приложений. В данном случае для параметров (Volume Types, Privilege Escalation, Running as Non-root, Capabilities) должны быть явно заданы значения из перечня разрешенных.
Использование PSS стоит начать с режима аудита для того, чтобы выявить потенциальные проблемы, и далее плавно переходить к enforce-режиму. Стоит не забывать отслеживать возникающие нарушения, прежде чем вводить жесткие требования безопасности.
PodSecurityContext
SecurityContext — это поле, которое может использоваться как на уровне Pod'а, так и на уровне контейнера. Оно указывает kubelet, с какими привилегиями/ограничениями должен быть запущен Pod и все контейнеры в его составе.
Рекомендации по доступным настройкам SecurityContext приведены в официальной документации.
RBAC API
К объектам RBAC (Role Based Access Control) API относятся следующие объекты, с помощью которых выполняется управление правами:
ClusterRole, Role — объект, содержащий набор прав;
ClusterRoleBinding, RoleBinding — объект, с помощью которого присваиваются права, указанные в ClusterRole/Role для пользователя или группы пользователей. Для того чтобы создавать гибкие и безопасные политики доступа к ресурсам, можно использовать RoleMixing — сочетание различных специализированных ролей.
При работе с объектами RBAC стоит:
назначать только необходимые права для пользователя/сервиса (избегать использования «*» в verbs/resources);
ограничить права на чтение секретов и ConfigMap’ов;
предоставлять доступ в пределах namespace, в редких случаях используя ClusterRole.
Защита Worker-нод
Worker-ноды кластера могут быть атакованы через уязвимости в контейнерах (образах), через уязвимости хостовой ОС, а также благодаря ошибкам в конфигурации политик безопасности, манифестов.
Выделим следующие направления по защите Worker-нод:
Безопасность ОС;
Безопасность используемых образов и манифестов.
Безопасность ОС
Для обеспечения безопасности ОС всех нод кластера необходим комплексный подход, который включает в себя как технические, так и организационные меры.
Важно обеспечить строгий контроль доступа к нодам (например, «ужесточив» настройки подключения по SSH). Необходимо регулярно выполнять установку обновлений безопасности для ОС, пакетов. Рекомендуется выполнить харденинг ОС в соответствии с лучшими практиками (например, ориентироваться на CIS Benchmark) и выполнять регулярный аудит и мониторинг параметров безопасности нод кластера. Также в данном подходе будет полезным использование специально подготовленных ОС, например Talos.
Безопасность используемых образов и манифестов
Для своевременного обнаружения уязвимостей в образах контейнеров рекомендуется выполнять регулярное сканирование как на этапе разработки (в рамках CI/CD пайплайна), так и в хранилище образов (Container Registry).
Не менее важную роль играет обеспечение безопасности манифестов (K8s, helm и т.д.). Использование в них небезопасных настроек (отсутствие SecurityContext или использование параметра hostPath, запуск с правами root и т.д.) может стать причиной компрометации всего кластера. Для минимизации таких рисков рекомендуется использовать инструменты анализа используемых манифестов (kube-linter, Checkov и др.) на этапе разработки. Контроль за соблюдением политик безопасности на этапе развертывания может выполняться с помощью Admission-Controller’ов.
Защита контейнеров в runtime
После того как контейнер запущен, важно обеспечить контроль за его работой. Для этого используются инструменты, отслеживающие поведение Pod’ов, выявляющие аномалии и блокирующие вредоносные действия.
В качестве примера можно привести Falco — инструмент для мониторинга системных вызовов и обнаружения подозрительной активности (запуск шелла в контейнере или изменение критических файлов), имеет возможность написания собственных правил.
Векторы атак. Обнаружение и расследование инцидентов
Описанные способы защиты Control Plane помогают понять, какие механизмы защиты от злоумышленников могут использоваться в кластере. В этом разделе мы взглянем на методы, используемые злоумышленниками для компрометации Kubernetes-кластеров, и индикаторы компрометации, которые нужно отслеживать.
В первую очередь нужно определить источник информации, который предоставит необходимые данные. В Kubernetes это будут Audit Logs (необходимо выполнить предварительную настройку kube-api-сервера). С их помощью мы получим информацию о всех запросах (get, list, create, update, delete, exec, patch и post), которые выполнялись в кластере.
Начальный доступ
1. Анонимный неавторизованный доступ
Любой запрос в Kubernetes, если в нем не указаны учетные данные для аутентификации, автоматически расценивается как запрос от "system:anonymous". Если аутентификация анонимных запросов включена, они могут быть выполнены в зависимости от разрешений, назначенных этому пользователю или группе "system:unauthenticated". Так, в основном пользователь system:anonymous используется системными сервисами по типу livez, healthz, readyz.
Рекомендации
Начиная с версии 1.6+, анонимный доступ включен по умолчанию (при использовании отличного от AlwaysAllow режима авторизации). Рекомендуется отключить его с помощью флага –anonymous-auth=false в kube-apiserver), а также:
настроить права RBAC для анонимного пользователя;
обеспечить мониторинг анонимных запросов к endpoint’ам, отличным от системных;
обеспечить мониторинг создания/изменения RoleBinding для system:anonymous;
отслеживать IP-адрес и User-Agent, который выполняет запрос.
Также стоит анализировать историю запросов подозрительных пользователей и сервисных аккаунтов на наличие возможных показателей компрометации (примеры: использование команды kubectl auth can-i, запросы к API /apis/authorization.k8s.io/v1/selfsubjectrulesreviews и т.д.).
2. Публикация приложений, потенциально содержащих уязвимости
Представим ситуацию, когда в кластере опубликовано веб-приложение, в котором могут содержаться различные уязвимости. Злоумышленник может использовать их для выполнения произвольного кода, получения доступа к информации в БД, ресурсам кластера и т.д. В случае, если он получит доступ к Pod’у, на котором оно запущено, у него появится возможность перемещения по кластеру и поиска другой чувствительной информации.
В качестве рекомендаций по защите можно привести следующие советы:
выполнять статический и динамический анализ ПО;
обеспечить работу приложений с минимально необходимым набором прав;
обеспечить сетевую изоляцию развернутого приложения (сетевые политики, расположение в разных namespace и т.д.);
настроить мониторинг активности приложений.
Выполнение команд
1. Создание reverse-shell
Для закрепления в кластере и получения возможности удаленного выполнения команд, управления ресурсами, доступа к другим сервисам злоумышленники часто используют reverse-shell (подключение к машине злоумышленника из кластера). Получив доступ к Pod’у, злоумышленник выполняет команду для создания rever-shell’а.
Рекомендации
Использовать инструменты для мониторинга активности в кластере Kubernetes.
Настроить мониторинг создания reverse-shell’ов как в Pod’ах, так и на нодах.
Ограничить с помощью сетевых политик взаимодействие между Pod’ами / пространствами имен.
Ограничить использование привилегированных контейнеров.
2. Выполнение команд в пространстве имен kube-system
В пространстве kube-system располагаются системные компоненты кластера. Если злоумышленник получит возможность выполнения команд в этом пространстве имен, он сможет скомпрометировать весь кластер, т.к. компоненты в kube-system имеют высокие привилегии и доступ к ключевым компонентам кластера.
Рекомендации
Логирование действий пользователей в kube-system.
Логирование exec-запросов в kube-system.
Настроить сетевые политики для ограничения доступа к Pod'ам в kube-system.
3. Создание/модификация объектов Role с привилегированными ролями
При настройке RBAC API стоит уделять большое внимание назначаемым правам, в том числе отслеживать попытки создания/изменения объектов Role|Cluster Role и *RoleBinding'ов для них, особенно с привилегированными ролями (admin, cluster-admin).
Рекомендации
Логировать создание связей с объектами Role|ClusterRole.
Анализировать создаваемые Binding'и: какая роль назначается, какими правами обладает.
Проверять пространства имен, учитывая, какие службы там могут находиться.
Проверять, так ли необходимы запрашиваемые привилегии каждому пользователю.
Отслеживать IP-адрес и User-Agent, который выполняет запрос.
Доступ к учетным данным
1. Перечисление секретов (Secret Enumeration)
Секреты в Kubernetes используются для хранения чувствительных данных (пароли, токены, API-ключи и др.). Возможность перечисления секретов предоставляет злоумышленнику доступ к критически важной информации, которая может быть использована для дальнейшей компрометации кластера или инфраструктуры.
Рекомендации
Настроить логирование попыток перечисления секретов с помощью Get, List, Watch-запросов, используя, например, пороговые значения.
Логировать источник таких запросов и анализировать прошлую активность.
Следить за User Agent'ом (вдруг это автоматизированный перебор).
Настроить права RBAC для тех пользователей и сервисов, которым это необходимо.
Не хранить секреты в контейнерах.
2. Подозрительное делегирование
В K8s делегирование (impersonating) в основном используется сервисными аккаунтами. Стоит внимательно следить за попытками обычных пользователей воспользоваться таким функционалом, это может указывать на действия злоумышленника.
В случае, если злоумышленник имеет доступ к учетным данным (токены, сертификаты), которые обладают правами на выполнение запросов с делегированием, он может попытаться получить доступ к ресурсам, обычно недоступным для этой учетной записи. Также возможность выполнения запросов от имени другого пользователя открывает возможность получения доступа к другим пространствам имен, созданию новых Pod’ов с повышенными привилегиями и т.д.
Рекомендации
Логировать имя пользователя, инициировавшего запрос и от имени которого выполняются запросы.
Настроить и регулярно проверять правила RBAC.
Отслеживать IP-адрес пользователя, создавшего запрос.
Проводить анализ запроса и привилегий, которые могут быть получены (от имени другого пользователя).
3. Действия сервисных аккаунтов
В своей работе сервисные аккаунты следуют определенной логике и ожидаемому поведению. Однако, если злоумышленник получает доступ к сервисному аккаунту, он может использовать его для выполнения действий, выходящих за рамки его обычного поведения. Если такой запрос будет отклонен (из-за недостаточных прав, нарушения политик безопасности, ошибок в запросе), это может служить индикатором подозрительной активности в кластере.
Рекомендации
Обеспечивать мониторинг отклоненных запросов от сервисных аккаунтов.
Выполнять регулярный аудит объектов Role|RoleBinding (Cluster) для минимизации избыточных прав.
Анализировать запрашиваемые ресурсы и пространства имен, свойственные этому сервисному аккаунту.
Отслеживать IP-адрес и User-Agent, который выполняет запрос.
Закрепление
Создание службы NodePort
Служба NodePort упрощает доступ и отладку приложений без необходимости использования дополнительных служб, однако слабый контроль за ее использованием увеличивает поверхность атаки, затрудняет мониторинг и управление безопасностью. Она позволяет предоставить доступ к приложению путем открытия порта на ноде кластера.
В случае, если применяются другие способы публикации приложений в кластере, создание службы NodePort может быть индикатором подозрительной активности в кластере.
Рекомендации
Отслеживать попытки создания служб NodePort.
Анализировать, какое приложение планируется опубликовать с помощью этой службы.
Ограничить доступ только с доверенных IP-адресов.
Рассмотреть возможность перехода к Ingress или LoadBalancer.
Побег из Pod'а с использованием параметра HostPath
Опция hostPath позволяет монтировать файлы и разделы с ноды в Pod. При неосторожном монтировании критически важных разделов (/etc, /, /dev, /var/lib/kubelet) злоумышленник получает возможность изменения файлов на ноде, чтения чувствительных данных, повышения привилегий.
Рекомендации
Использовать Admission-контроллеры для отслеживания и блокировки создания Pod'ов с параметрами HostPath (Kyverno, OPA).
Ограничить использование параметра HostPath только необходимыми директориями/файлами.
Настроить использование Pod Security Standard (PSS).
На тему использования Kyverno и OPA GateKeeper советуем ознакомиться с материалами конференции DevOpS Conf:
«Kyverno: старт без грабель» (сценарии использования Kyverno при погружении в тему Policy Engines);
«Gatekeeper, или Как защитить K8s и не деградировать» (рассказ о выполнении best practices и безопасного развертывания сервисов).
Итоги
В заключение хотелось бы сказать пару слов о том, что безопасность в кластере Kubernetes можно обеспечить как с помощью встроенных средств, так и «наложенных» Open Source или enterprise-решений. В случае Open Source неудобство может заключаться в том, что придется управлять большим набором инструментов, когда как в enterprise-решениях они будут спрятаны внутри.
Рекомендуем начать защиту своего кластера Kubernetes с простых шагов, которые не потребуют много ресурсов на первых этапах.
Проведите аудит безопасности вашего кластера с помощью Open-Source-инструментов, таких как Kube Hunter, KubeBench, Kube Scan, Kubesec и др.
Обеспечьте проверку развертываемых yaml-манифестов, например, с помощью kube-score, kube-linter и др.
Проведите аудит выданных прав доступа к кластеру.
Настройте сетевой доступ к компонентам prod-инфраструктуры.
По результатам выполнения этих шагов у вас будет отчет о нынешнем состоянии безопасности кластера, а также рекомендации по ее повышению. Проверка манифестов позволит избежать ошибок конфигурации и снизить риск возникновения проблем в будущем.
Обеспечение безопасности кластера Kubernetes — комплексный процесс. В дальнейшем рекомендуется автоматизировать проверки безопасности и выполнить тонкую настройку всех используемых инструментов.
Более детально ознакомиться с рекомендациями, порядком их выполнения для защиты сред контейнеризации вы можете в нашем фреймворке Jet Container Security Framework J.
Для большего погружения в тему обратите внимание на следующие доклады:
1. «Как собрать контейнер и не вооружить хакера» — Антон Жаболенко, Алексей Федулаев.
2. «Безопасность Kubernetes-кластеров: вредные советы» — Дмитрий Евдокимов.
3. «SOAR в Kubernetes малой кровью» — Дмитрий Евдокимов.
Автор: Илья Лебедев, инженер по информационной безопасности, «Инфосистемы Джет».