Skip to content

Latest commit

 

History

History
116 lines (104 loc) · 20.3 KB

README-RU.md

File metadata and controls

116 lines (104 loc) · 20.3 KB
Raw

Kubernetes Security Checklist and Requirements - All in One

  • Аутентификация
    • Рекомендуется использовать сторонний IdP сервер в качестве стороннего провайдера для аутентификации пользователей в API Kubernetes (например, с использованием OIDC). Администраторам кластера не рекомендуется использовать токены service account для аутентификации.
    • Для управления сертификатами внутри кластера (пользовательские и сервисные) рекомендуется использовать сторонний централизованный сервис управления сертификатами.
    • Пользовательские УЗ должны быть персонализированы. Названия сервисных УЗ должны отражать назначение УЗ и используемые права доступа.
  • Авторизация
    • Для каждого кластера должна быть проработана ролевая модель доступа.
    • Для кластера Kubernetes должен быть настроен Role-Based Access Control (RBAC). Права должны назначаться в пределах пространства имен проекта по принципу наименьших привилегий (least privilege) и разделения полномочий (seperation of duties) (RBAC-tool).
    • Все сервисы должны обладать уникальным service account с настроенными правами RBAC.
    • Разработчики не должны иметь доступ к препродуктивной и продуктивной среде без согласования с командой безопасности.
    • Запрещено использовать средства user impersonation (возможность выполнять действия под другой УЗ).
    • Запрещено использовать анонимную аутентификацию, кроме /healthz, /readyz, /livez. Исключения должны согласовываться с командой безопасности.
    • Администраторы кластера и функциональное сопровождение должны взаимодействовать с API кластера и инфраструктурными сервисами через решение контроля привилегированных пользователей (Teleport, Boundary).
    • Все компоненты каждой информационной системы должны быть разделены на отдельные пространства имен (namespaces), при этом рекоммендуется избегать ситуации, когда одна и та же команда сопровождения ответственная за разные пространства имен.
    • Права RBAC необходимо регулярно подвергать аудиту (KubiScan, Krane)
  • Безопасная работа с секретами
    • Сформированные секреты храниться в защищенном стороннем хранилище (HashiCorp Vault, Conjur), либо в etcd в зашифрованном виде.
    • Объекты типа "secrets" должны добавляться в контейнер с использованием механизма volumeMount или механизма secretKeyRef. Для сокрытия секретов в исходных кодах может использоваться, например, инструмент sealed-secret.
  • Безопасность конфигурации кластера
    • Должно быть включено повсеместное использование шифрования TLS между компонентами кластера.
    • Должно использоваться стороннее решение, поддерживающее механизм настраиваемых политик безопасности (OPA, Kyverno).
    • Конфигурацию кластера рекомендуется соответствовать CIS Benchmark за исключением требований к PSP.
    • Рекомендуется использовать только последние версии компонентов кластера (CVE list).
    • Для сервисов с повышенными требованиями к безопасности рекомендуется использовать low-lever run-time с высокой степенью изоляцией (gVisior, Kata-runtime).
    • Конфигурация кластера должна регулярно подвергаться аудиту (Kube-bench, Kube-hunter, Kubestriker)
  • Логирование
    • Необходимо фиксировать все случаи изменения прав доступа в кластере.
    • Необходимо фиксировать все операции с секретами (включая неавторизованный доступ к секретам). При этом фиксация значений секретов должна быть исключена.
    • Необходимо фиксировать все действия администраторов сопровождения и администраторов кластера, связанных с развертыванием приложений и изменением их конфигурации.
    • Необходимо фиксировать все случаи изменения параметров, системных настроек или конфигурации всего кластера. В том числе средствами на уровне ОС.
    • Все зарегистрированные события безопасности, как на уровне кластера, так и на уровне приложения должны передаваться в централизованную систему аудита/логирования (SIEM).
    • Используемая подсистема аудита должна быть расположена вне кластера Kubernetes.
    • Выстроить процессы observability и visibility для того, чтобы понимать происходящее в инфраструктуре и сервисах(Luntry, WaveScope)
    • На всех нодах должно быть запущено стороннее решение для реализации мониторинга безопасности (Falco, Sysdig, Aqua Enterpise, NeuVector, Prisma Cloud Compute).
  • Безопасность конфигурации ОС
    • Администрирование хостов должно осуществляться через стороннее решение, логирующее действия пользователя (в т.ч. bastion host). Также может использоваться ОС без возможности удаленного подключения.
    • Рекомендуется конфигурировать ОС и ПО в соответствии с baseline и стандартами (CIS, NIST).
    • Рекомендуется регулярно сканировать пакеты на наличие уязвимостей(OpenSCAP профили, Lynis).
    • Рекомендуется регулярно обновлять версию ядра ОС (CVEhound).
  • Безопасность сети
    • Все пространства имен должны обладать NetworkPolicy. Взаимодействия между пространствами имен должны быть ограничены NetworkPolicy по принципам Least Privileges (Inspektor Gadget).
    • При организации микросервисного взаимодействия, рекомендуется, чтобы каждый сервис проходил аутентификацию и авторизацию (Istio, Linkerd, Consul).
    • Интерфейсы компонентов кластера и инструментов инфраструктуры запрещено публиковать в сети в Интернет.
    • Инфраструктурные сервисы, control plane и хранилища данных должны быть расположены в отдельном VLAN на изолированных нодах.
    • Внешний пользовательский трафик, проходящий внутрь кластера, должен инспектироваться с помощью WAF.
    • Рекомендуется разделять ноды кластера, взаимодействующие с сетью Интернет (DMZ), от нод кластера, взаимодействующих с внутренними сервисами. Разграничение может быть в рамках одного кластера, либо в рамках двух разных кластеров (DMZ и VLAN).
  • Безопасность конфигурации разворачиваемых приложений
    • Запрещено запускать поды под учетной записью root - UID 0.
    • Для всех сервисов должен быть установлен параметр runAsUser.
    • Должен быть выставлен параметр allowPrivilegeEscalation - false.
    • Запрещен запуск привилегированного пода (privileged: true).
    • Рекомендуется выставлен параметр readonlyRootFilesystem - true.
    • Запрещено использовать hostPID и hostIPC.
    • Запрещено использовать hostNetwork.
    • Запрещено использование небезопасных системных вызовов (sysctl):
      • kernel.shm*,
      • kernel.msg*,
      • kernel.sem,
      • fs.mqueue.*,
    • Запрещено использовать hostPath.
    • Должны быть выставлены ограничения на CPU/RAM. Значения должны быть минимально достаточным для работы контейнеризированного приложения.
    • Capabilities должны выдаваться по принципу наименьших привилегий (drop 'ALL', после чего перечисление всех необходимых сapabilities для работы приложения, при этом запрещено использовать:
      • CAP_FSETID,
      • CAP_SETUID,
      • CAP_SETGID,
      • CAP_SYS_CHROOT,
      • CAP_SYS_PTRACE,
      • CAP_CHOWN,
      • CAP_NET_RAW,
      • CAP_NET_ADMIN,
      • CAP_SYS_ADMIN,
      • CAP_NET_BIND_SERVICE)
    • Запрещено использовать пространство имен по умолчанию (default).
    • Приложение должно иметь профиль seccomp, apparmor или selinux по принципам least privileges (Udica, Oci-seccomp-bpf-hook, Go2seccomp, Security Profiles Operator).
    • Конфигурация приложений должна регулярно подвергаться аудиту (Kics, Kubeaudit, Kubescape, Conftest, Kubesec, Checkov)
  • Безопасная разработка образа
    • Запрещено использовать конструкцию RUN с sudo.
    • Рекомендуется не использовать тэг latest.
    • Вместо инструкции ADD требуется использовать COPY.
    • Запрещено использовать автоматическое обновление пакетов через apt-get upgrade, yum update, apt-get dist-upgrade.
    • Необходимо явно указывать версии устанавливаемых пакетов. Для определения перечня используемых пакетов могут использоваться инструменты для построения SBOM (Syft).
    • Запрещено хранить чувствительную информацию (пароли, токены, сертификаты) в Dockerfile.
    • Состав пакетов в образе контейнера должен быть минимально достаточен для работы. Неиспользуемые в ходе работы контейнеризированного приложения пакеты должны отсутствовать в образе контейнера.
    • Не рекомендуется устанавливать wget, curl, netcat, внутри образа и контейнера продуктивного приложения.
    • Состав пробрасываемых в контейнер портов должен быть минимально достаточен для работы. Неиспользуемые в ходе работы контейнеризированного приложения порты не должны использоваться в контейнере.
    • Рекомендуется использовать dockerignore для предотвращения помещения чувствительной информации внутрь образа.
    • Рекомендуется использовать минимальное количество слоев используя многоступенчатую сборку.
    • Рекомендуется использовать WORKDIR в качестве абсолютного пути. Не рекомендуется использовать cd вместо WORKDIR.
    • При скачивании пакетов из Интернета в процессе сборки, рекомендуется проверять целостность этих пакетов.
    • Рекомендуется остерегаться рекурсивного копирование с помощью конструкции COPY . .
    • Запрещено запускать средства удаленного управления в контейнере.
    • По результатам сканирования образов Docker должна формироваться подпись образа, которая будет проверяться перед развертыванием (Notary, Cosign).
    • Dockerfile должны проверяться в процессе разработки автоматизированными сканнерами (Kics, Hadolint, Conftest).
    • Все образы должны проверяться в жизненном цикле приложения автоматизированными сканнерами (Trivy, Clair, Grype).
    • Должна быть выстроена безопасность CI и CD, а также безопасность цепочки поставок(SLSA)

Kubernetes logo

Полезный контент

  • Обсуждение на тему безопасности Kubernetes можно продолжить в нашем Telegram-чате: DevSecOps Chat
  • Канал автора чеклиста: DevSecOps Wine
  • Чеклист был подготовлен при поддержке автора канала k8security