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

В Deckhouse Kubernetes Platform (DKP) доступны следующие механизмы:

  • контроль целостности пользовательской нагрузки при запуске — проверка подписи образов на этапе валидации запросов к API Kubernetes;
  • контроль целостности работающих контейнеров — рантайм-аудит;
  • защита целостности модулей DKP — установка модулей в виде неизменяемых образов.

Контроль целостности образов на уровне контейнерного рантайма (CRI) — проверка криптографической подписи образов и защита распакованных слоев от изменения — реализован только в редакциях DKP CSE Lite и CSE Pro. В остальных редакциях этот механизм недоступен (подробнее — в разделе «Контроль целостности образов на уровне CRI»).

Контроль целостности образов на уровне CRI

Проверка криптографической подписи образов при загрузке и старте контейнера, а также контроль неизменяемости распакованных слоев образа с помощью DM-Verity, реализованы на уровне containerd и доступны только в редакциях DKP CSE Lite и CSE Pro. Подписи образов платформы проверяются встроенным в containerd набором публичных сертификатов; закрытый ключ подписи принадлежит поставщику платформы, добавить собственный ключ для проверки нельзя. Подробнее об этом механизме — в документации DKP CSE.

В остальных редакциях DKP (CE, BE, SE, SE+, EE) проверки подписи образов на уровне CRI нет:

  • При использовании containerd v2 применяется снапшоттер EROFS: каждый слой OCI-образа преобразуется в отдельный файл в формате EROFS и монтируется только для чтения. Это снижает риск подмены данных в уже распакованных на узле образах, но не исключает его полностью и не заменяет проверку подлинности образа. Подробнее о переходе на containerd v2 — в разделе «Миграция container runtime на containerd v2».
  • Проверка хеш-суммы SHA-256 при скачивании образа, выполняемая containerd, защищает от повреждения данных при передаче, но не подтверждает подлинность образа: она не позволяет определить, кем был собран образ.

Чтобы контролировать целостность и подлинность образов пользовательских приложений в этих редакциях, используйте проверку подписи на этапе валидации запросов к API Kubernetes (подробнее — в разделе «Контроль целостности пользовательской нагрузки при запуске»).

Контроль целостности пользовательской нагрузки при запуске

Доступно в следующих редакциях DKP: SE+, EE, CSE Lite, CSE Pro.

Целостность и подлинность образов пользовательских приложений проверяются на этапе валидации запросов к API Kubernetes — до создания пода, а не на уровне CRI. Механизм реализован модулем admission-policy-engine и использует подписи, созданные с помощью Cosign.

Последовательность контроля целостности при запуске:

  1. На этапе сборки образ подписывается закрытым ключом с помощью Cosign. Подпись публикуется в хранилище образов контейнеров отдельным тегом и не изменяет сам образ.
  2. В кластере создается ресурс SecurityPolicy с параметром policies.verifyImageSignatures, в котором указываются публичные ключи и шаблоны адресов образов.
  3. При создании или обновлении пода валидационный вебхук передает запрос Gatekeeper, который обращается к компоненту Ratify.
  4. Ratify проверяет подпись образа по указанным публичным ключам.
  5. Если подпись отсутствует или не соответствует указанным ключам, создание пода запрещается.

Дополнительно можно ограничить перечень хранилищ образов контейнеров, из которых разрешен запуск подов, с помощью параметра policies.allowedRepos ресурса OperationPolicy.

Подробнее о настройке — в разделе «Проверка подписи образов».

Контроль целостности работающих контейнеров

Аудит событий безопасности в DKP включает в себя анализ событий ядра Linux и аудита событий API Kubernetes. Это позволяет отслеживать, что приложения в подах работают в неизменном виде, соответствуют ожидаемому состоянию и не были модифицированы.

Для аудита используются:

  • встроенные правила;
  • пользовательские правила, которые можно добавлять с использованием синтаксиса условий Falco.

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

Подробнее о настройках аудита безопасности можно почитать в разделе «Аудит событий безопасности».

Защита целостности модулей DKP

Начиная с версии 1.74, модули DKP устанавливаются не в виде каталога с файлами, а в виде образа в формате EROFS, который подключается только для чтения через механизм ядра DM-Verity. Это защищает содержимое уже установленного модуля от изменения на узле: перезаписать файлы модуля в смонтированном образе невозможно, а DM-Verity проверяет блоки образа при обращении к ним.

Механизм включается автоматически, если на узле, где работает контроллер DKP (по умолчанию — master-узел), файловая система erofs зарегистрирована в ядре, то есть соответствующий модуль ядра загружен или встроен в ядро. Проверить это можно командой:

grep -w erofs /proc/filesystems

Если файловая система erofs недоступна, DKP продолжит работу и будет устанавливать модули обычным способом, без защиты их целостности. Переключение происходит без отдельного алерта, поэтому проверяйте доступность erofs заранее.

DKP загружает модуль ядра erofs и настраивает его автозагрузку только на узлах, где в качестве container runtime используется containerd v2. Если на master-узлах используется containerd v1, модуль erofs может оказаться незагруженным, и модули DKP будут установлены без защиты целостности — даже если ядро поддерживает erofs.

Чтобы гарантированно задействовать механизм, переведите master-узлы на containerd v2 либо обеспечьте загрузку модуля erofs средствами операционной системы.

При использовании этого механизма следует учитывать следующее:

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

Дополнительные ресурсы