Использование платформы Kubernetes для управления контейнерной средой
Используя контейнерную среду в IT-инфраструктуре, компания может прийти к ситуации, когда развертывать множество отдельных образов и контейнеров и управлять ими становится проблематично и неэффективно. Для масштабирования и автоматизации развертывания и управления контейнерной средой используют Kubernetes.
Kubernetes — платформа с открытым исходным кодом для управления контейнерными приложениями на нескольких узлах.
Кроме удобства, Kubernetes обеспечивает высокую доступность и отказоустойчивость приложений, дает возможность управлять ресурсами облачного хранилища более эффективно, что позволяет сократить расходы на инфраструктуру.
Основные компоненты Kubernetes:
узлы, или ноды (nodes) — физические или виртуальные машины, на которых запускаются контейнеры;
кластер — набор устройств (физических или виртуальных), объединенных для работы с Kubernetes. Кластер включает в себя узлы и мастер-узел (master node), который управляет кластером;
контроллеры (controllers) — автоматизируют и контролируют состояние кластера;
поды (pods) — группа контейнеров, работающих вместе на одном узле и запускаемых как единое целое;
управляющий план (control plane) — набор компонентов, обеспечивающий управление и контроль над кластером. Мастер-узел может быть составной частью управляющего плана, но управляющий план может включать и другие компоненты, не связанные с мастер-узлом.
этикетки (labels) — пары «ключ — значение», которые используются для идентификации и организации ресурсов;
сетевые политики (network policies) — определяют, какие сетевые соединения разрешены между контейнерами;
конфигурационные файлы (config files) — описывают желаемое состояние кластера.
В упрощенном виде это можно представить следующим образом:
Рисунок 1. Упрощенная структура Kubernetes
Использование Kubernetes требует определенных знаний и навыков. Необходимо правильно настроить кластер, установить параметры масштабирования и управления ресурсами, а также уметь работать с Kubernetes API и инструментами командной строки.
Платформа позволяет управлять большим количеством образов и контейнеров, которые, в свою очередь, обеспечивают работу множества приложений и могут содержать в себе конфиденциальную информацию. Неправильный подход к настройке и управлению системой может привести к серьезным проблемам кибербезопасности.
Результативный подход к работе с платформой Kubernetes должен включать в себя:
Надежность аутентификации и авторизации
Необходимо настроить правильные политики доступа и аутентификации, чтобы предотвратить несанкционированный доступ к контейнерам.
Защиту данных
Необходимо защитить данные, хранимые в контейнерах, от несанкционированного доступа и утечек. Для этого нужно использовать шифрование и правильно настроить политики доступа.
Мониторинг безопасности
Необходимо настроить процессы мониторинга и реагирования на события кибербезопасности для кластера Kubernetes и контейнеров, чтобы быстро обнаруживать и реагировать на любые угрозы.
Обновления безопасности
Необходимо регулярно обновлять Kubernetes и его компоненты, чтобы устранять уязвимости.
Использование безопасных образов контейнеров
Необходимо использовать только проверенные и безопасные образы контейнеров, чтобы избежать использования образов со встроенным вредоносным ПО и проблемами в параметрах безопасности.
Платформа Kubernetes должна быть под пристальным вниманием специалистов информационной безопасности. Конфигурация платформы — это комплексная задача, для выполнения которой необходимо соблюдать множество требований. Однако безопасно настроенная система поможет предотвратить реализацию недопустимых событий.
Рекомендации по усилению защиты контейнерных сред на базе Kubernetes
Кибератака редко базируется на одной-единственной ошибке в конфигурации сервиса или на уязвимости компонента системы. Каждая слабость в эшелонах безопасности может позволить злоумышленнику расширить площадь атаки и в итоге привести к реализации недопустимого для организации события.
Kubernetes не является исключением. Платформа оперирует одним или множеством кластеров, каждый из которых может обрабатывать чувствительную для компании информацию или являться критически важным сервисом, — это делает ее уязвимой перед множеством распространенных угроз:
Утечка данных. Например, злоумышленник реализует атаку типа man in the middle на сетевом уровне для перехвата данных между подом и внешними системами;
Несанкционированный доступ к кластеру и отдельным его компонентам. Например, использование интерфейса взаимодействия между узлами, или нодами (nodes), и master node (Kubelet API), который по умолчанию обрабатывает запрос без предварительной авторизации, получение с его помощью доступа к нодам и создание контейнера с правами администратора кластера;
Запуск вредоносных контейнеров: использование кода и образов из недостоверных источников, в которых вшиты бэкдоры или вредоносное программное обеспечение;
Использование уязвимостей. Несвоевременное обновление компонентов платформы и связанных систем может привести к потере контроля над серверами в результате эксплуатации уязвимостей, например CVE-2023-3676;
Использование некорректной конфигурации кластеров и подов. Образы монтируются в директорию узла, в результате чего злоумышленник, получив доступ к контейнеру, легко реализует «побег из контейнера» и получает доступ к нодам или возможность развертывания контейнера в режиме Privileged;
Атаки, направленные на повышение привилегий и негативное воздействие на платформу, например DDoS-атаки.
В связи с этим следует усиливать безопасность Kubernetes в инфраструктуре организации. Для этого следует обратить внимание на приведенные ниже аспекты, которые напрямую влияют на уровень кибербезопасности системы.
1. Безопасная сетевая инфраструктура
Безопасная настройка сетевой инфраструктуры включает в себя ограниченное использование портов и протоколов, управление сетью и контроль трафика, контроль доступа к API-серверу Kubernetes, в том числе:
использование сетевых политик (network policies) для всех пространств имен (namespaces). Взаимодействие между пространствами имен должно быть ограничено в соответствии с принципом минимальных привилегий (default-deny policy);
обеспечение аутентификации и авторизации каждого сервиса при организации микросервисного взаимодействия;
расположение инфраструктурных сервисов, master node и хранилища данных в отдельном VLAN на изолированных узлах;
проверку внешнего пользовательского трафика, передаваемого в кластер, с помощью межсетевого экрана уровня приложений (WAF);
отделение узлов кластера, взаимодействующих с интернетом, от узлов кластера, взаимодействующих с внутренними сервисами. Разграничение может осуществляться внутри одного кластера или в разных кластерах.
2. Безопасная конфигурация OC
Цель безопасной конфигурации ОС — уменьшение числа потенциальных векторов атак и оптимизация развертывания контейнеров. Для этого необходимо:
выполнять администрирование узлов с использованием программных продуктов, позволяющих регистрировать действия пользователей;
проводить регулярное сканирование ПО и пакетов обновлений на наличие уязвимостей;
регулярно обновлять ядро используемой ОС и устанавливать актуальные обновления безопасности;
использовать immutable OC по типу Talos или Flatcar.
3. Настройка аутентификации и авторизации
Рекомендации предназначены для двух типов пользователей, существующих в системе: service accounts (аккаунты, управляемые Kubernetes API) и users (пользователи, управляемые внешними независимыми сервисами). Для усиления безопасности следует:
проработать ролевую модель доступа (RBAC) для каждого кластера. Права должны быть назначены в пределах пространства имен проекта по принципу наименьших привилегий и разделения полномочий;
проводить регулярный аудит назначенных привилегий RBAC;
назначить всем сервисам уникальные сервисные учетные записи с настроенными правами RBAC;
отказаться от использования токенов сервисных учетных записей для аутентификации администраторов кластера;
использовать сторонний сервер Identity Provider для аутентификации пользователей в API Kubernetes;
использовать централизованный сервис для управления сертификатами внутри кластера, например встроенный Certificate Signing Requests (CSR API), внешний центр сертификации Let’s Encrypt или сторонний инструмент HashiCorp Consul;
не предоставлять разработчикам доступ к продуктивной среде без согласования с функцией ИБ;
запретить использование средств имперсонации, позволяющих выполнять действия от имени других пользователей;
запретить использование анонимной аутентификации (кроме конечных точек /healthz, /readyz, /livez). Исключения должны согласовываться с функцией ИБ;
использовать системы контроля привилегированных пользователей (PAM) для администраторов кластеров и других привилегированных пользователей;
разделить компоненты каждой информационной системы на отдельные пространства имен.
4. Безопасная работа с аутентификационными данными
В Kubernetes аутентификационные данные представлены в виде Secrets. Secret — это объект, который хранит конфиденциальную информацию: парольную фразу, ключевую пару, ключ шифрования, API-токен. Доступ к этим данным нужно ограничить и использовать их только внутри кластера.
В связи с этим необходимо:
хранить сформированные Secrets в защищенном стороннем хранилище или в базе данных etcd в зашифрованном виде;
не хранить конфиденциальную информацию в объектах типа ConfigMap;
использовать механизмы volumeMount или secretKeyRef при добавлении в контейнер объектов типа Secrets;
настроить права доступа к этим Secrets с помощью команды chmod.
5. Безопасная конфигурация кластера
Следует обеспечить защищенность данных и безопасный доступ к ресурсам системы, особенно для крупных распределенных кластеров с использованием логической изоляции:
применяя повсеместное шифрование трафика при обмене данными между компонентами кластера и используя протокол mTLS для обмена данными между сервисами (например, Istio — опенсорсный проект для решения задач, связанных с трафиком, безопасностью и мониторингом в микросервисах);
используя только последние версии компонентов кластера с актуальными обновлениями безопасности;
применяя набор инструментов для развертывания низкоуровневых сред запуска контейнеров (low-level runtime) с высокой степенью изоляции для сервисов с повышенными требованиями к безопасности;
проводя регулярный аудит конфигурации кластера на соответствие требованиям информационной безопасности.
6. Безопасность образов Docker
Kubernetes оперирует большим количеством контейнеров, и безопасность каждого из них всецело влияет на общий уровень безопасности системы. В отношении контейнеров требуется:
не использовать автоматическое обновление пакетов через механизмы apt-get upgrade, yum update, apt-get dist-upgrade;
явно указывать версии устанавливаемых пакетов программного обеспечения;
не хранить важную информацию (пароли, токены, сертификаты) в файле Dockerfile;
использовать файл *.*dockerignore, чтобы предотвратить добавление важной информации внутрь образа;
использовать минимально необходимый для работы набор пакетов ПО в образе контейнера. Пакеты, которые не используются в процессе работы контейнеризированного приложения, не должны содержаться в образе контейнера;
не использовать инструменты типа wget, curl и netcat внутри образа и контейнера продуктивного приложения;
использовать минимально необходимый для работы перечень сетевых портов, перенаправляемых в контейнер;
использовать минимальное количество слоев при многоступенчатой сборке;
проверять целостность пакетов ПО при их загрузке из интернета в процессе сборки;
не использовать средства удаленного управления в контейнере;
не использовать тег latest;
проверять файлы Dockerfile автоматизированными сканерами в процессе разработки;
проверять образы автоматизированными сканерами на протяжении их жизненного цикла;
по результатам сканирования Docker-образов формировать их подписи, которые будут проверяться перед развертыванием, и формировать Software Bill of Materials (SBOM);
организовать безопасность процессов CI/CD и цепочки поставок.
Дополнительную информацию о повышении уровня безопасности контейнеров Docker вы можете узнать в статье - .
не запускать поды от имени учетной записи суперпользователя root;
установить для всех сервисов параметр runAsUser;
установить для параметра allowPrivilegeEscalation значение false;
установить для параметра readonlyRootFilesystem значение true;
установить для параметров hostPID, hostIPC, hostNetwork и hostPath значение false;
запретить использование небезопасных системных вызовов kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.*;
установить ограничения на потребление ресурсов процессора и памяти, которые минимально необходимы для работы контейнеризированных приложений;
не использовать пространство имен по умолчанию;
разворачиваемые приложения должны обладать профилями seccomp, AppArmor или SELinux;
проводить регулярный аудит конфигурации разворачиваемых приложений на соответствие требованиям информационной безопасности;
имеет смысл использовать cluster as a service, когда нет разных команд на одном кластере;
необходимо настроить планировщик (scheduler) и использовать свойства ограничения узла кластера (taints, affinity), чтобы исключить запуск контейнеров разного уровня важности на одном узле.
8. Журналирование
Высокий уровень безопасности невозможно обеспечить без контроля и мониторинга системы, находящейся в инфраструктуре организации. Для отслеживания событий в Kubernetes необходимо:
включить функцию встроенного аудита Kubernetes с передачей данных для анализа в SIEM;
регистрировать в файлах журнала регистрации событий:
все попытки изменения прав доступа в кластере;
все операции с Secrets, включая неавторизованный доступ к ним. При этом запись значений Secrets должна быть исключена;
все действия администраторов кластера и других привилегированных пользователей, связанные с развертыванием приложений и изменением их конфигурации;
все случаи изменения конфигурации ОС или всего кластера;
разместить подсистему журналирования вне кластера Kubernetes;
развернуть на всех нодах сторонние решения для мониторинга событий информационной безопасности;
передавать все зарегистрированные события информационной безопасности в SIEM-систему.
Безопасность контейнеров на примере платформы Docker
Безопасность контейнеров на примере платформы Docker
Александр Кравченко
Николай Пиховкин
Рисунок 1. Упрощенная структура Kubernetes