Требования к безопасности Kubernetes

7. Безопасность Kubernetes7. Безопасность Kubernetes

Yandex Managed Service for Kubernetes предоставляет окружение для работы с контейнеризованными приложениями в инфраструктуре Yandex Cloud. Вы можете разворачивать, масштабировать и управлять приложениями в контейнерах с помощью Kubernetes.

Все действия внутри узла Kubernetes являются ответственностью пользователя. Пользователь несет ответственность за безопасность узлов и их корректную настройку в соответствии с требованиями PCI DSS и других стандартов безопасности.

За безопасность API Kubernetes отвечает Yandex Cloud.

Пользователь отвечает за правильный выбор настроек безопасности Managed Service for Kubernetes, в том числе выбор канала и расписания обновлений.

ОбщееОбщее

7.1 Ограничено использование критичных данных7.1 Ограничено использование критичных данных

При работе с сервисом Managed Service for Kubernetes для выполнения требований PCI DSS и других стандартов безопасности запрещается:

• Использовать критичные данные в именах и описаниях кластеров, групп узлов, пространств имен, сервисов, подов.
• Использовать критичные данные в метках узлов Kubernetes и метках ресурсов сервисов Yandex Cloud.
• Указывать критичные данные в манифестах подов.
• Указывать критичные данные в etcd в открытом виде.
• Записывать критичные данные в логи Managed Service for Kubernetes.

Инструкции и решения по выполнению:

Вручную исправьте названия или наполнения для манифестов и других конфигурационных файлов, если в них используются критичные данные.

7.2 Ресурсы изолированы друг от друга7.2 Ресурсы изолированы друг от друга

Придерживайтесь максимальной изоляции между ресурсами везде, где это возможно:

• Под каждый «большой» проект используется отдельная организация.
• Под каждую команду разработки используется отдельное облако.
• Под каждый сервис используется отдельный кластер Kubernetes в отдельном каталоге.
• Под каждый микросервис используется отдельное пространство имен.
• У облаков должны отсутствовать разделяемые ресурсы, у участников облаков должен быть доступ только к своему облаку.

Возможны и менее строгие схемы изоляции, например:

• Проекты развернуты в разных облаках.
• Команды разработки используют отдельные каталоги.
• Сервис представлен отдельным кластером Kubernetes.
• Микросервисы используют разные пространства имен.

7.3 Нет доступа к API Kubernetes и группам узлов из недоверенных сетей7.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:

  • NGINX Ingress Controller.
  • Application Load Balancer Ingress-контроллера.

7.4 В Managed Service for Kubernetes настроены аутентификация и управление доступом7.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 пользователя облака.

7.5 В Managed Service for Kubernetes используется безопасная конфигурация7.5 В Managed Service for Kubernetes используется безопасная конфигурация

В Managed Service for Kubernetes пользователь управляет всеми настройками групп узлов, настройками мастера — только частично. Пользователь отвечает за безопасность всего кластера.

Для безопасной конфигурации Kubernetes, включая конфигурацию узлов, существует стандарт CIS Kubernetes Benchmark. В Yandex Cloud группы узлов Kubernetes по умолчанию разворачиваются с конфигурацией, которая соответствует стандарту CIS Kubernetes Benchmark.

7.6 Шифрование данных и управление секретами Managed Service for Kubernetes выполняются в формате ESO as a Service7.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. Решение доступно в Cloud Marketplace в базовом упрощенном сценарии — External Secrets Operator с поддержкой Yandex Lockbox.

Рекомендуемый наиболее безопасный вариант шифрования секретов — ESO as a Service (External Secrets Operator as a service). При использовании ESO глобальный администратор имеет доступ к пространству имен с установленным ESO, а администраторы отдельных пространств имен создают себе объекты SecretStore (в которых указывают IAM авторизованные ключи доступа к своим секретам Lockbox). В случае компрометации данного объекта SecretStore скомпрометирован будет только авторизованный ключ одного пространства имен, а не всех как в случае, например, схемы Shared ClusterSecretStore.

Инструкции и решения по выполнению:

• Инструкция по работе с External Secrets и Yandex Lockbox из описания проекта.
• Инструкция по работе с External Secrets и Yandex Lockbox из документации Yandex Cloud.

7.7 Docker-образы хранятся в реестре Container Registry с настроенным периодическим сканированием образов7.7 Docker-образы хранятся в реестре Container Registry с настроенным периодическим сканированием образов

Для эффективного обеспечения безопасности рекомендуется использовать Container Registry для хранения Docker-образов, которые разворачиваются в Managed Service for Kubernetes. Это позволит оперативно реагировать на появление новых уязвимостей в образах с помощью встроенного переодического сканирования на уязвимости.

Сканирование на уязвимости должно проводиться не реже одного раза в неделю. Это поможет своевременно обнаруживать и устранять уязвимости в образах, что существенно снизит риски несанкционированного доступа к вашим ресурсам и повысит уровень безопасности вашей инфраструктуры.

Использование Container Registry для хранения образов также обеспечит централизованное управление версиями образов, что упростит процесс обновления и управления безопасностью.

Инструкции и решения по выполнению:

• Инструкция по сканированию Docker-образа по расписанию.

7.8 Используется одна из трех последних версий Kubernetes и ведется мониторинг обновлений7.8 Используется одна из трех последних версий Kubernetes и ведется мониторинг обновлений

Для Kubernetes доступно как автоматическое, так и ручное обновление кластера и группы узлов. Вы можете в любое время запросить обновление кластера Kubernetes или его узлов вручную до последней поддерживаемой версии. Ручные обновления обходят любые настроенные окна обслуживания и исключения обслуживания. Kubernetes регулярно выпускает обновления. Для соответствия стандартам ИБ:

• выберите подходящий канал обновления и настройте автоматическое применение обновлений, либо применяйте обновления вручную сразу после публикации в выбранном канале;
• проверьте, что настройки обновлений соответствуют стандартам ИБ;
• используйте одну из трех последних версий Kubernetes, так как любые обновления, в том числе обновления безопасности, выпускаются только для них.

yc managed-kubernetes list-versions

Инструкции и решения по выполнению:

• Инструкция как обновить кластер автоматически.
• Инструкция как обновить кластер вручную.

7.9 Настроено резервное копирование7.9 Настроено резервное копирование

Для обеспечения непрерывности работы и защиты данных рекомендуется использовать резервное копирование в Managed Service for Kubernetes, поскольку оно позволяет быстро восстановить работу сервиса без потери данных и времени на восстановление после сбоя или аварии. Данные в кластерах Kubernetes надежно хранятся и реплицируются в инфраструктуре Yandex Cloud. Однако в любой момент вы можете сделать резервные копии данных из групп узлов кластеров Kubernetes и хранить их в Yandex Object Storage или другом хранилище.

Инструкции и решения по выполнению:

Вы можете создавать резервные копии данных из групп узлов кластера Kubernetes с помощью инструмента Velero. Этот инструмент поддерживает работу с дисками Yandex Cloud с помощью CSI-драйвера Kubernetes, и позволяет создавать моментальные снимки дисков томов.

При работе с Velero, установленным вручную, вы можете использовать nfs, emptyDir, локальный или любой другой тип тома, в котором нет встроенной поддержки моментальных снимков. Чтобы использовать такой тип тома, задействуйте плагин restic при установке Velero. Velero, установленный из Cloud Marketplace, плагин restic не включает.

• Инструкция по резервному копированию кластера Kubernetes в Object Storage.

7.10 Используются чек-листы для безопасного создания и использования Docker-образа7.10 Используются чек-листы для безопасного создания и использования Docker-образа

Практики безопасного создания и использования Docker-образа необходимы для защиты от потенциальных уязвимостей, вредоносных программ и несанкционированного доступа к данным. Они помогают обеспечить целостность образа, его соответствие стандартам безопасности и предотвратить возможные угрозы при его использовании в инфраструктуре. Используйте данные чеклисты для выполнения требований по безопасному созданию образов:

• Dockerfile best practices.
• Kubernetes Security Checklist and Requirements.

Контролировать Dockerfile в процессе CI/CD можно с помощью утилиты Conftest.

При проверке минимальных образов или образов distroless (distroless images), в которых отсутствует shell, рекомендуется использовать ephemeral cointainers.

7.11 Используется политика безопасности Kubernetes7.11 Используется политика безопасности Kubernetes

Требования Pod Security Standards от Kubernetes позволяют предотвращать угрозы, связанные с объектами Kubernetes, такие как несанкционированный доступ к конфиденциальным данным или выполнение вредоносного кода.

Эти требования помогают обеспечить безопасность и надежность работы приложений в кластере Kubernetes. Для их реализации можно использовать встроенный инструмент Kubernetes Pod Security Admission Controller или открытое программное обеспечение, например, OPA Gatekeeper или Kyverno.

Инструкции и решения по выполнению:

• Для контроля соответствия требованиям Pod Security Standarts также можно использовать следующие инструменты в рамках CI/CD:

  • Kyverno CLI
  • The gator CLI

• Инструмент Kubesec.

7.12 Настроен сбор аудитных логов для расследований инцидентов7.12 Настроен сбор аудитных логов для расследований инцидентов

События, доступные пользователю в рамках сервиса Managed Service for Kubernetes, можно разделить на следующие уровни:

• события Kubernetes API (Kubernetes Audit logging);
• события узлов Kubernetes;
• события подов Kubernetes;
• метрики Kubernetes;
• Flow logs Kubernetes.

Подробнее о настройке сбора событий аудита на разных уровнях см. в разделе Сбор, мониторинг и анализ аудитных логов Managed Service for Kubernetes.

Managed Service for Kubernetes предоставляет возможность проводить аудит текущей ролевой модели в сервисе. Для этого в консоли управления откройте страницу кластера Kubernetes и перейдите на вкладку Управление доступом.

Также можно использовать:

• KubiScan.
• Krane.
• Аудитные логи Yandex Audit Trails.