С ростом популярности 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 — комплексный процесс. В дальнейшем рекомендуется автоматизировать проверки безопасности и выполнить тонкую настройку всех используемых инструментов.