9. Безопасность Kubernetes
Введение
Yandex Managed Service for Kubernetes предоставляет окружение для работы с контейнеризованными приложениями в инфраструктуре Yandex Cloud. Вы можете разворачивать, масштабировать и управлять приложениями в контейнерах с помощью Kubernetes.
Все действия внутри узла Kubernetes являются ответственностью пользователя. Пользователь несет ответственность за безопасность узлов и их корректную настройку в соответствии с требованиями PCI DSS и других стандартов безопасности.
За безопасность API Kubernetes отвечает Yandex Cloud.
Пользователь отвечает за правильный выбор настроек безопасности Managed Service for Kubernetes, в том числе выбор канала и расписания обновлений.
9.1 Ограничено использование критичных данных
При работе с сервисом Managed Service for Kubernetes для выполнения требований PCI DSS и других стандартов безопасности запрещается:
- Использовать критичные данные в именах и описаниях кластеров, групп узлов, пространств имен, сервисов, подов.
- Использовать критичные данные в метках узлов Kubernetes и метках ресурсов сервисов Yandex Cloud.
- Указывать критичные данные в манифестах подов.
- Указывать критичные данные в etcd в открытом виде.
- Записывать критичные данные в логи Managed Service for Kubernetes.
- Убедитесь, что в именах и описаниях кластеров, групп узлов, пространств имен, сервисов, подов нет критичных данных.
- Проверьте конфигурационные файлы на предмет критичных данных.
- В консоли управления
выберите каталог, в котором расположен инстанс Managed Service for Kubernetes. - В списке сервисов выберите Managed Service for Kubernetes.
- Убедитесь, что в метках узлов Kubernetes и метках ресурсов сервисов Yandex Cloud нет критичных данных.
Инструкции и решения по выполнению:
Вручную исправьте названия или наполнения для манифестов и других конфигурационных файлов, если в них используются критичные данные.
9.2 Ресурсы изолированы друг от друга
Придерживайтесь максимальной изоляции между ресурсами везде, где это возможно:
- Под каждый «большой» проект используется отдельная организация.
- Под каждую команду разработки используется отдельное облако.
- Под каждый сервис используется отдельный кластер Kubernetes в отдельном каталоге.
- Под каждый микросервис используется отдельное пространство имен.
- У облаков должны отсутствовать разделяемые ресурсы, у участников облаков должен быть доступ только к своему облаку.
Возможны и менее строгие схемы изоляции, например:
- Проекты развернуты в разных облаках.
- Команды разработки используют отдельные каталоги.
- Сервис представлен отдельным кластером Kubernetes.
- Микросервисы используют разные пространства имен.
Проверьте, что обеспечена максимальная изоляция между ресурсами везде, где это возможно.
9.3 Нет доступа к API Kubernetes и группам узлов из недоверенных сетей
Не рекомендуется открывать доступ к API Kubernetes и группам узлов из недоверенных сетей, в том числе из интернета. В случае необходимости используйте средства межсетевого экранирования, в частности группы безопасности.
Инструкции и решения по выполнению:
-
Используйте инструменты для настройки network policy с помощью плагинов Calico (базовый) или Cilium CNI (продвинутый) в Yandex Cloud, используя
default deny
правила для входящего и исходящего трафика по умолчанию и разрешать только необходимый трафик. -
Выделите отдельный кластер Kubernetes для конечных точек, которые взаимодействуют с интернетом, либо отдельные группы узлов (с помощью механизмов: Taints and Tolerations
+ Node affinity ). Таким образом, выделяется DMZ, и в случае компрометации узлов из интернета поверхность атаки ограничится. -
Чтобы организовать входящий сетевой доступ к рабочим нагрузкам по протоколу HTTP/HTTPS используйте ресурс Ingress
. Существует как минимум 2 варианта Ingress-контроллера, которые можно использовать в Yandex Cloud:
9.4 В Managed Service for Kubernetes настроены аутентификация и управление доступом
Для работы кластера Kubernetes необходимы два сервисных аккаунта: сервисный аккаунт кластера и сервисный аккаунт группы узлов. Управление доступом учетных записей IAM к ресурсам Managed Service for Kubernetes выполняется на следующих уровнях:
- Сервисные роли Managed Service for Kubernetes (доступ к Yandex Cloud API): позволяют управлять кластерами и группами узлов (например, создать кластер, создать/редактировать/удалить группу узлов и т.д.).
- Сервисные роли для доступа к Kubernetes API: позволяют управлять ресурсами кластера через Kubernetes API (например, стандартные действия с Kubernetes: создание, удаление, просмотр пространств имен, работа с подами, deployments, создание ролей и т.д.). Доступны только базовые глобальные роли на уровне всего кластера:
k8s.cluster-api.cluster-admin
,k8s.cluster-api.editor
иk8s.cluster-api.viewer
. - Примитивные роли: глобальные примитивные роли IAM, которые содержат в себе сервисные роли (например, примитивная роль admin содержит в себе и сервисную административную роль и административную роль для доступа к Kubernetes API).
- Стандартные роли Kubernetes: внутри самого кластера Kubernetes доступно создание ролей и кластерных ролей средствами Kubernetes. Таким образом можно управлять доступом учетных записей IAM на уровне пространства имен. Для назначения IAM ролей на уровне пространства имен возможно вручную создавать объекты RoleBinding в необходимом пространстве имен, указывая в поле «subjects name» идентификатор IAM пользователя облака.
Проверьте, что рекомендации, указанные выше, выполняются.
9.5 В Managed Service for Kubernetes используется безопасная конфигурация
В Managed Service for Kubernetes пользователь управляет всеми настройками групп узлов, настройками мастера — только частично. Пользователь отвечает за безопасность всего кластера.
Для безопасной конфигурации Kubernetes, включая конфигурацию узлов, существует стандарт CIS Kubernetes Benchmark
- С помощью инструмента kube-bench
проверьте конфигурацию группы узлов по стандарту CIS Kubernetes Benchmark. Инструмент официально поддерживает группы узлов Yandex Cloud. - Starboard Operator
— это бесплатный инструмент, который позволяет автоматизировать сканирование образов на уязвимости и проверку конфигурации на соответствие CIS Kubernetes Benchmark. Starboard Operator поддерживает интеграцию с kube-bench и используется для его автоматического запуска.
9.6 Шифрование данных и управление секретами Managed Service for Kubernetes выполняются в формате ESO as a Service
Шифрование секретов на уровне Kubernetes etcd необходимо выполнять встроенным механизмом сервиса Yandex Cloud.
Работу с Kubernetes secrets рекомендуется выполнять с помощью решений класса SecretManager. В Yandex Cloud таким решением является сервис Yandex Lockbox.
Интеграция Yandex Lockbox с Kubernetes выполнена с помощью открытого проекта External Secrets
Рекомендуемый наиболее безопасный вариант шифрования секретов — ESO as a Service (External Secrets Operator as a service). При использовании ESO глобальный администратор имеет доступ к пространству имен с установленным ESO, а администраторы отдельных пространств имен создают себе объекты SecretStore
Инструкции и решения по выполнению:
- Инструкция по работе с External Secrets и Yandex Lockbox из описания проекта
. - Инструкция по работе с External Secrets и Yandex Lockbox из документации Yandex Cloud.
9.7 Docker-образы хранятся в реестре Container Registry с настроенным периодическим сканированием образов
Для эффективного обеспечения безопасности рекомендуется использовать Container Registry для хранения Docker-образов, которые разворачиваются в Managed Service for Kubernetes. Это позволит оперативно реагировать на появление новых уязвимостей в образах с помощью встроенного переодического сканирования на уязвимости.
Сканирование на уязвимости должно проводиться не реже одного раза в неделю. Это поможет своевременно обнаруживать и устранять уязвимости в образах, что существенно снизит риски несанкционированного доступа к вашим ресурсам и повысит уровень безопасности вашей инфраструктуры.
Использование Container Registry для хранения образов также обеспечит централизованное управление версиями образов, что упростит процесс обновления и управления безопасностью.
- В консоли управления
выберите каталог, которому принадлежит реестр с Docker-образами. - Выберите реестр в сервисе Container Registry.
- Перейдите на вкладку Сканер уязвимостей и нажмите кнопку Изменить настройки.
- Убедитесь, что сканирование Docker-образов по расписанию включено и оно проходит не реже, чем раз в неделю.
Инструкции и решения по выполнению:
9.8 Используется одна из трех последних версий Kubernetes и ведется мониторинг обновлений
Для Kubernetes доступно как автоматическое, так и ручное обновление кластера и группы узлов. Вы можете в любое время запросить обновление кластера Kubernetes или его узлов вручную до последней поддерживаемой версии. Ручные обновления обходят любые настроенные окна обслуживания и исключения обслуживания. Kubernetes регулярно выпускает обновления. Для соответствия стандартам ИБ:
- выберите подходящий канал обновления и настройте автоматическое применение обновлений, либо применяйте обновления вручную сразу после публикации в выбранном канале;
- проверьте, что настройки обновлений соответствуют стандартам ИБ;
- используйте одну из трех последних версий Kubernetes, так как любые обновления, в том числе обновления безопасности, выпускаются только для них.
Чтобы узнать список доступных версий для кластера Kubernetes:
- Перейдите на страницу каталога и выберите сервис Managed Service for Kubernetes.
- Нажмите на имя нужного кластера Kubernetes.
- Нажмите кнопку Редактировать в правом верхнем углу.
- Получите список доступных версий в поле Версия Kubernetes блока Конфигурация мастера.
Чтобы узнать список доступных версий для группы узлов Kubernetes:
- Перейдите на страницу каталога и выберите сервис Managed Service for Kubernetes.
- Нажмите на имя нужного кластера Kubernetes и перейдите на вкладку Управление узлами.
- Выберите нужную группу узлов Kubernetes в списке и нажмите кнопку Редактировать в правом верхнем углу.
- Получите список доступных версий в поле Версия Kubernetes.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы получить список доступных версий, выполните команду:
yc managed-kubernetes list-versions
Чтобы получить список доступных версий, воспользуйтесь методом list.
Инструкции и решения по выполнению:
9.9 Настроено резервное копирование
Для обеспечения непрерывности работы и защиты данных рекомендуется использовать резервное копирование в Managed Service for Kubernetes, поскольку оно позволяет быстро восстановить работу сервиса без потери данных и времени на восстановление после сбоя или аварии. Данные в кластерах Kubernetes надежно хранятся и реплицируются в инфраструктуре Yandex Cloud. Однако в любой момент вы можете сделать резервные копии данных из групп узлов кластеров Kubernetes и хранить их в Yandex Object Storage или другом хранилище.
Проверьте наличие резервных копий данных из групп узлов кластеров Kubernetes.
Инструкции и решения по выполнению:
Вы можете создавать резервные копии данных из групп узлов кластера Kubernetes с помощью инструмента Velero
При работе с Velero, установленным вручную, вы можете использовать nfs
9.10 Используются чек-листы для безопасного создания и использования Docker-образа
Практики безопасного создания и использования Docker-образа необходимы для защиты от потенциальных уязвимостей, вредоносных программ и несанкционированного доступа к данным. Они помогают обеспечить целостность образа, его соответствие стандартам безопасности и предотвратить возможные угрозы при его использовании в инфраструктуре. Используйте данные чеклисты для выполнения требований по безопасному созданию образов:
Контролировать Dockerfile в процессе CI/CD можно с помощью утилиты Conftest
При проверке минимальных образов или образов distroless (distroless images), в которых отсутствует shell, рекомендуется использовать ephemeral cointainers
Проверьте наличие чеклистов для выполнения требований по безопасному созданию образов.
9.11 Используется политика безопасности Kubernetes
Требования Pod Security Standards от Kubernetes
Эти требования помогают обеспечить безопасность и надежность работы приложений в кластере Kubernetes. Для их реализации можно использовать встроенный инструмент Kubernetes Pod Security Admission Controller
Проверьте выполнение требований Pod Security Standards от Kubernetes.
Инструкции и решения по выполнению:
-
Для контроля соответствия требованиям Pod Security Standarts также можно использовать следующие инструменты в рамках CI/CD:
- Kyverno CLI
- The gator CLI
- Kyverno CLI
-
Инструмент Kubesec
.
9.12 Настроен сбор аудитных логов для расследований инцидентов
События, доступные пользователю в рамках сервиса Managed Service for Kubernetes, можно разделить на следующие уровни:
- события Kubernetes API (Kubernetes Audit logging);
- события узлов Kubernetes;
- события подов Kubernetes;
- метрики Kubernetes;
- Flow logs Kubernetes.
Подробнее о настройке сбора событий аудита на разных уровнях см. в разделе Сбор, мониторинг и анализ аудитных логов Managed Service for Kubernetes.
Managed Service for Kubernetes предоставляет возможность проводить аудит текущей ролевой модели в сервисе. Для этого в консоли управления
Также можно использовать:
- KubiScan
. - Krane
. - Аудитные логи Yandex Audit Trails.
Убедитесь, что выполняется сбор аудитных логов.