Контроль целостности

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

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

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

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

Проверка криптографической подписи образов при загрузке и старте контейнера, а также контроль неизменяемости распакованных слоёв образа с помощью DM-Verity, реализованы на уровне containerd и доступны только в редакциях DP Certified Core и Certified Pro. В этих редакциях используется доработанная версия containerd. Корневой хеш DM-Verity рассчитывается для каждого слоя образа на этапе сборки платформы и сверяется containerd при разворачивании образа. Контроль включает проверку при обращении к блокам образа и периодическую перепроверку:

• после разворачивания DM-Verity проверяет блоки образа при каждом обращении к ним во время работы контейнера;
• дополнительно containerd периодически (по умолчанию раз в час) перепроверяет уже запущенные контейнеры в защищаемых неймспейсах. При этом containerd повторно проверяет подпись манифеста образа и полностью сверяет слои образа с корневым хешем DM-Verity (veritysetup verify). Слои проверяются не все сразу. Очередь обрабатывается по одному контейнеру в минуту, поэтому полный проход по узлу занимает тем больше времени, чем больше на нём контейнеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это отдельный механизм, не связанный с контролем целостности образов на уровне CRI: DM-Verity здесь применяется контроллером DP к образу модуля платформы, а не containerd к слоям образов контейнеров. Поэтому ограничение по редакциям, описанное в разделе «Контроль целостности образов на уровне CRI», на него не распространяется.

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

grep -w erofs /proc/filesystems

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

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

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

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

• Кастомные ресурсы модуля admission-policy-engine