Связаться с намиПодключиться

Безопасность Kubernetes

Статья создана
Обновлена 3 апреля 2025 г.

Раздел содержит рекомендации пользователям Yandex Cloud по настройкам безопасности в Yandex Managed Service for Kubernetes.

Разделение ответственности

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

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

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

Критичные данные

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

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

Ресурсная модель

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

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

У облаков должны отсутствовать разделяемые ресурсы, у участников облаков должен быть доступ только к своему облаку.

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

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

Сетевая безопасность Managed Service for Kubernetes

Не рекомендуется открывать доступ к API Kubernetes и группам узлов из недоверенных сетей, в том числе из интернета.
В случае необходимости используйте средства межсетевого экранирования, в частности группы безопасности. Ниже в разделе приведены ссылки на инструкции по настройке межсетевого экранирования в группах безопасности.

Сегментация

Уровень облака

Выполните ограничение сетевого доступа к API Kubernetes (мастер) и группам узлов согласно инструкции для групп безопасности.

В случае использования ALB в качестве Ingress Gateway также необходимо:

  1. Применить группу безопасности на ALB.

  2. Дополнительно применить группу безопасности на группу узлов:

    • Тип источника: <группа безопасности, которая применена на ALB>.
    • Типа назначения: группа узлов.
    • Диапазон портов: 30000-32767.

Уровень Kubernetes

Выполните ограничение сетевого доступа внутри Kubernetes с помощью механизма Network Policy.

В Yandex Cloud можно использовать два сетевых плагина:

Рекомендуется использовать default deny правила для входящего и исходящего трафика по умолчанию и разрешать только необходимый трафик.

Для генерации политик можно использовать встроенный в Cilium CNI hubble для анализа трафика либо анализировать его вручную. Также на рынке представлены решения, которые помогают автоматически генерировать сетевые политики.

Полезные примеры сетевых политик представлены в репозитории.

Полезный инструмент для создания и валидации обычных и продвинутых сетевых политик представлен по ссылке.

Организация входящего сетевого доступа

Рекомендуется выделить отдельный кластер Kubernetes для конечных точек, которые взаимодействуют с интернетом, либо отдельные группы узлов (с помощью механизмов: Taints and Tolerations + Node affinity). Таким образом, выделяется DMZ, и в случае компрометации узлов из интернета поверхность атаки ограничится.

Чтобы организовать входящий сетевой доступ к рабочим нагрузкам по протоколу HTTP/HTTPS используйте ресурс Ingress.

Существует как минимум 2 варианта Ingress-контроллера, которые можно использовать в Yandex Cloud:

Преимущества Application Load Balancer Ingress-контроллера:

  • интеграция с облачным сервисом Yandex Certificate Manager;
  • отсутствие необходимости установки контроллера в кластер, так как все разворачивается на стороне Application Load Balancer.

Ограничение доступа к метаданным ВМ группы узлов

Для всех подов необходимо создать network policy, которая блокирует сетевой трафик на адрес 169.254.169.254, либо использовать default-deny политику из примера. Политика должна блокировать доступ к метаданным группы узлов из рабочих нагрузок, так как они содержат чувствительные данные, например токен сервисного аккаунта, привязанного к узлу.

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

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: iam-user-aje0jndkhkvu04ek #имя объекта RoleBinding
namespace: micro1-ns 
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- kind: User
name: aje0jndkq855llvu04ek #идентификатор пользователя облака

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

Пример настройки ролевых моделей и политик в Managed Service for Kubernetes.

Безопасная конфигурация Managed Service for Kubernetes

Безопасная конфигурация

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

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

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

Инструмент kube-bench позволяет проверить конфигурацию группы узлов по стандарту CIS Kubernetes Benchmark. Инструмент официально поддерживает группы узлов Yandex Cloud.

Здесь можно ознакомится с примерами запуска kube-bench на узлах.

Также kube-bench поддерживает интеграцию со Starboard Operator, другим продуктом для автоматического запуска kube-bench.

Starboard Operator — это бесплатный инструмент, который позволяет автоматизировать сканирование образов на уязвимости и проверку конфигурации на соответствие CIS Kubernetes Benchmark.

Интеграция Starboard и Yandex Container Registry с целью сканирования запущенных образов

Контроль целостности (FIM — File integrity monitoring)

Контроль целостности файлов на стороне группы узлов необходимо выполнять на двух уровнях:

  • файлы ОС узла, например конфигурационные файлы;
  • файлы контейнера, например критичные файлы, которое пользовательское приложение пишет в том.

Файлы ОС узла

Можно использовать, например, Osquery в качестве агента, который устанавливается на узлы с помощью DaemonSet и использует конкретные каталоги узла, монтируемые как том в контейнер DaemonSet (прокинутая файловая система).

Комплексное решение в Osquery and kubequery in K8s.

Файлы контейнера

Один из способов решения данной задачи:

  1. Использовать readOnlyRootFilesystem в подах.
  2. Каталоги, в которые требуется записывать данные, монтировать как отдельные тома: как emptydir или как отдельные диски.

Если монтировать каталоги как emptydir, файлы будут храниться на узле в папке /var/lib/kubelet/pods/PODUID/volumes/kubernetes.ioempty-dir/VOLUMENAME. Данную папку можно мониторить в целях контроля целостности решением Osquery как файлы ОС узла.

В случае отдельных дисков (не emptydir), тома можно монтировать в режиме read к вышеупомянутому DaemonSet с Osquery.

Контроль целостности файлов узлов Kubernetes также можно выполнять с помощью инструментов указанных в разделе Контроль целостности.

Существуют специфические бесплатные решения для узлов Kubernetes от Google либо Argus и в том числе file-integrity-operator.

Шифрование данных и управление секретами Managed Service for Kubernetes

Шифрование секретов на уровне Kubernetes etcd необходимо выполнять встроенным механизмом сервиса Yandex Cloud.

Работу с Kubernetes secrets рекомендуется выполнять с помощью решений класса SecretManager. В Yandex Cloud такое решением является сервис Yandex Lockbox.

Интеграция Yandex Lockbox с Kubernetes выполнена с помощью открытого проекта External Secrets. Решение доступно в Cloud Marketplace в базовом упрощенном сценарии — External Secrets Operator с поддержкой Yandex Lockbox.

Полезные инструкции по работе с External Secrets:

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

Описано множество способов разделения доступа к секретам в рамках данного инструмента.

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

Шифрование в состоянии передачи (in transit)

Для шифрования in transit рекомендуется использовать TLS-взаимодействие между подами. В случае невозможности работы по TLS используйте service mesh-решения:

Шифрование в состоянии покоя (at rest)

Если необходимо шифрование данных при хранении, можно использовать:

  • Key Management Service для шифрования данных на уровне приложения (в том числе при использовании persistent volumes).
  • Свой способ организации шифрования данных, но в этом случае защита ключей и процедуры управления ключами являются полностью ответственностью пользователя.

Защита от вредоносного кода в Managed Service for Kubernetes

Защиту от вредоносного кода в Kubernetes можно осуществлять на двух уровнях:

  • Защита уровня Container Registry;
  • Защита уровня ОС узлов Kubernetes.

Сканер безопасности в Container Registry.

Чтобы защитить уровень хостов контейнеризации, можно использовать различные платные и бесплатные решения классов «Runtime security» и «Antivirus engine». Примеры бесплатных решений:

Также необходимо использовать встроенную в Kubernetes поддержку AppArmor и Seccomp.

Анализ логов безопасности Kubernetes в ELK: аудит-логи, policy engine, falco.

Управление уязвимостями Managed Service for Kubernetes

Yandex Cloud в рамках Managed Service for Kubernetes отвечает за управление уязвимостями и обновлениями безопасности мастера.Пользователю необходимо самостоятельно управлять уязвимостями в рабочих узлах Kubernetes.

Сканирование уязвимостей

Сканирование уязвимостей можно разбить на следующие уровни:

  • сканирование уязвимостей уровня образов;
  • сканирование уязвимостей ОС узлов Kubernetes.

Сканирование уязвимостей уровня образов описано в разделе Защита от вредоносного кода в Managed Service for Kubernetes.

Примеры универсальных бесплатных решений для сканирование уязвимостей ОС узлов Kubernetes указаны в разделе Требования к безопасности Kubernetes.

Также существуют специализированные платные и бесплатные решения для сканирования уязвимостей ОС узлов Kubernetes, которые позволяют сканировать хосты Kubernetes на предмет уязвимостей, например бесплатные kube-hunter и trivi (scan filesystem).

Обновления безопасности

Managed Service for Kubernetes регулярно выпускает обновления. Для соответствия стандартам ИБ:

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

Резервное копирование и восстановление

Настройте резервное копирование Managed Service for Kubernetes в соответствии с руководством. При хранении резервных копий в Object Storage необходимо следовать рекомендациям из раздела Безопасная конфигурация для Object Storage.

Политики безопасности Kubernetes

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

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

Примеры, в которых используется Kyverno:

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

Либо отдельный инструмент Kubesec.

Практики безопасного создания и использования Docker-образа

Используйте данные чеклисты для выполнения требований по безопасному созданию образов:

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

Защита runtime

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

Решение с использованием Osquery.

Разделение нагрузки по узлам

Нагрузки, которые имеют разные контексты безопасности (разную критичность обрабатываемых данных), необходимо обрабатывать на разных узлах Kubernetes. Для разделения нагрузок внутри кластера необходимо использовать разные группы узлов с разными настройками node labels и node taints. Эти настройки необходимо использовать вместе.

Сбор, мониторинг и анализ аудитных логов Managed Service for Kubernetes

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

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

Уровень Kubernetes API (Kubernetes Audit logging)

Сбор событий аудита с уровня Kubernetes API выполняется сервисом Cloud Logging.

Анализ логов безопасности Kubernetes в ELK: аудит-логи, policy engine, falco.

Уровень узлов Kubernetes

Сбор и экспорт событий уровня узлов Kubernetes выполняется аналогично сбору аудитных логов ОС.

Уровень подов Kubernetes

Сбор и экспорт событий уровня подов Kubernetes в различных вариантах описан в официальной документации Kubernetes.

Примеры сбора и экспорта логов подов:

В Cloud Marketplace доступны плагин Filebeat для передачи логов в Elastic и Fluent Bit с плагином Cloud Logging.

Метрики Kubernetes

Monitoring содержит ряд метрик, применимых для анализа доступности объектов Kubernetes и аномалий в поведении.

Инструкция по экспорту метрик Monitoring приведена в разделе Экспорт событий в SIEM.

Flow logs Kubernetes

Экспорт flow logs в Yandex Object Storage.

Аудит ролевой модели Managed Service for Kubernetes

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

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

Предыдущая
Чеклист безопасности аутентификации и авторизации
Следующая
Референсная архитектура для облачной инфраструктуры в изолированном режиме без доступа в интернет