Подсистема Security

В данном подразделе описывается архитектура подсистемы Security (подсистемы безопасности) Deckhouse Kubernetes Platform (DKP).

В подсистему Security входят следующие модули:

• admission-policy-engine — позволяет использовать в кластере политики безопасности согласно Kubernetes Pod Security Standards. Для реализации политик модуль использует Gatekeeper;
• runtime-audit-engine — реализует внутреннюю систему обнаружения угроз;
• operator-trivy — позволяет периодически сканировать кластер DKP на наличие уязвимостей;
• cert-manager — управляет TLS-сертификатами в кластере;
• secrets-store-integration — реализует доставку секретов в приложения Kubernetes-кластера путем подключения секретов, ключей и сертификатов из внешних хранилищ;
• secret-copier — автоматически копирует секреты в неймспейсы кластера.

В подразделе на данный момент описаны следующие компоненты подсистемы Security:

• контроль целостности;
• аудит событий безопасности.

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

В Deckhouse Kubernetes Platform (DKP) контроль целостности работает:

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

DKP обеспечивает контроль целостности контейнеров приложений на уровне контейнерного рантайма (CRI).

После скачивания образа приложения DKP проверяет его целостность, сверяя хеш-сумму SHA-256. Запуск контейнера возможен только при успешной проверке контрольной суммы.

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

1. Загрузка образа в локальное хранилище узла.
2. Извлечение метаданных образа, включая хеш-сумму SHA-256.
3. Верификация SHA-256 путем сравнения с эталонной.
4. Если хеш совпадает, проверка пройдена. Если хеш не совпадает, образ не запускается.

Для повышения уровня безопасности можно настраивать политики загрузки образов при использовании политик безопасности, чтобы гарантировать использование актуальных версий при запуске контейнеров.

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

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

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

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

Аудит событий безопасности Deckhouse Kubernetes Platform (DKP) основан на системе обнаружения угроз Falco. DKP запускает объединённые в DaemonSet агенты Falco на каждом узле, после чего те приступают к сбору системных вызовов ОС и данных, полученных в ходе аудита событий Kubernetes.

На каждом узле кластера запускается под Falco со следующими компонентами:

• falco — собирает события, обогащает их метаданными и отправляет в stdout;
• rules-loader — собирает данные с правилами из кастомных ресурсов FalcoAuditRules и сохраняет их в общую директорию;
• falcosidekick — принимает события от falco и экспортирует их в виде метрик во внешние системы;
• kube-rbac-proxy — защищает эндпоинт метрик falcosidekick от неавторизованного доступа.

Для анализа событий безопасности применяются правила, определяющие критерии подозрительного поведения. Каждое правило представляет собой выражение, содержащее определённое условие и написанное в соответствии с синтаксисом условий Falco.

В DKP предусмотрены следующие виды встроенных правил:

• правила для аудита Kubernetes, которые помогают выявить проблемы с безопасностью DKP и самим механизмом аудита. Эти правила расположены в контейнере falco по пути /etc/falco/k8s_audit_rules.yaml;
• нормативные правила, удовлетворяющие требованиям приказа ФСТЭК России №118 от 4 июля 2022 г. «Требования по безопасности информации к средствам контейнеризации». Эти правила fstec описаны в формате кастомного ресурса FalcoAuditRules.

Для добавления пользовательских правил используется кастомный ресурс FalcoAuditRules.

У каждого агента Falco есть сайдкар-контейнер с экземпляром сервиса shell-operator. Этот экземпляр считывает правила из ресурсов Kubernetes, конвертирует их в правила Falco и сохраняет правила в директорию /etc/falco/rules.d/ в поде. При добавлении нового правила Falco автоматически обновляет конфигурацию.