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

Платформа Deckhouse Kubernetes Platform (DKP) построена с учётом стандартов CIS Kubernetes Benchmark, что гарантирует высокий уровень защищённости как её внутренних модулей, так и инфраструктуры в целом.

Для подтверждения этого уровня в каждом кластере в фоновом режиме функционируют регулярные проверки на соответствие стандартам CIS. Итоговые данные визуализируются в Grafana на специальной панели Security / CIS Kubernetes Benchmark в виде детализированных отчётов. Кроме того, в DKP интегрирован инструмент для автоматического анализа контейнерных образов на наличие уязвимостей, функционирующий на базе Trivy. Для оперативной работы с данными сканирования предусмотрены команды, позволяющие выводить и фильтровать отчёты по уязвимостям и результатам CIS-тестов непосредственно в кластере.

Доступ к результатам сканирования, в том числе возможность просматривать ресурсы с результатами предоставляется пользователям, обладающим следующими ролями доступа:

• d8:manage:networking:viewer или выше;
• d8:manage:permission:module:operator-trivy:view.

Для просмотра результатов сканирования вашего приложения воспользуйтесь Grafana-дашбордом Security / Trivy Image Vulnerability Overview. Вы можете отфильтровать результаты по нужному пространству имён и ресурсу.

• Чтобы вывести все ресурсы, которые не прошли проверку:

• Чтобы выполнить поиск по идентификатору конкретной проверки:

• Чтобы выполнить поиск по описанию проверки:

Дашборды в Grafana:

• Security/Trivy Image Vulnerability Overview — сводный обзор уязвимостей в образах контейнеров, запущенных в кластере.

• Security/CIS Kubernetes Benchmark — результаты проверки соответствия кластера требованиям CIS Kubernetes Benchmark.

В Kubernetes-кластере информация о состоянии безопасности представлена двумя категориями отчетов. К первой категории относятся отчеты, характеризующие безопасность самого кластера: ClusterComplianceReport и RbacAssessmentReport. Ко второй категории — отчеты, описывающие безопасность рабочей нагрузки (нагрузки):

• VulnerabilityReport — содержит данные об уязвимостях в контейнерных образах;
• SbomReport — предоставляет детализированный состав программного обеспечения (SBOM);
• ConfigAuditReport — включает результаты аудита конфигурации объектов Kubernetes на предмет ошибок;
• ExposedSecretReport — сигнализирует о потенциальной утечке секретов внутри контейнеров.

В основе сбора этих данных лежит набор пользовательских ресурсов (CRD) от проекта Trivy Operator (разработка Aqua Security), которые интегрированы в DKP. Эти ресурсы стандартизируют представление результатов сканирования уязвимостей, анализа конфигурации и проверок безопасности. Далее приведено описание ключевых CRD, создаваемых operator-trivy, с практическими примерами и ссылками на официальную документацию.

Ресурс VulnerabilityReport аккумулирует данные сканирования контейнерных образов, используемых в рабочих нагрузках Kubernetes. В отчете приводится полный перечень известных уязвимостей, затрагивающих как системные пакеты, так и прикладное ПО, с сортировкой по критичности (Critical, High, Medium и др.).

При сканировании мультиконтейнерных подов operator-trivy генерирует отдельный экземпляр VulnerabilityReport для каждого контейнера. Эти ресурсы создаются в том же неймспейсе, что и исходная нагрузка, а их привязка к родительскому объекту Kubernetes реализуется через поле ownerReference. Шаблон именования отчета имеет следующий вид: <тип рабочей нагрузки>-<имя рабочей нагрузки>-<имя контейнера>.

Пример: 

Ресурс ConfigAuditReport предназначен для хранения результатов аудита конфигурации объектов Kubernetes, выполняемого с помощью инструментов статического анализа, таких как Trivy. В отчете приводится перечень выявленных замечаний, сгруппированных по функциональным категориям (например, "Security") и уровням критичности (Critical, High и т.д.).

Типовые проверки охватывают следующие аспекты:

• идентификатор запуска контейнера (проверка на запуск от root-пользователя);
• наличие и корректность ресурсных лимитов;
• параметры сетевой изоляции (использование hostNetwork, hostPID);
• настройки безопасности, предотвращающие эскалацию привилегий (например, allowPrivilegeEscalation).

ConfigAuditReport генерируется для всех типов ресурсов в пределах namespace: как для workloads (Pod, Deployment, StatefulSet), так и для вспомогательных объектов (Service, ConfigMap, Role, RoleBinding). Каждый отчет привязан к исходному объекту через поле ownerReference и хранится в том же пространстве имен. Имя ресурса формируется по шаблону <тип_объекта>-<имя_объекта>.

Пример:

Ресурс ExposedSecretReport предназначен для хранения результатов детектирования конфиденциальной информации внутри контейнерных образов, используемых в рабочих нагрузках Kubernetes. Отчет содержит перечень строк, идентифицированных как потенциальные секреты (токены, ключи доступа, пароли), с указанием точного местоположения в файловой системе образа. Каждая находка сопровождается метаданными: категория уязвимости, сработавшее правило проверки, уровень критичности и путь к файлу.

При сканировании мультиконтейнерных подов operator-trivy генерирует отдельный экземпляр ExposedSecretReport для каждого контейнера. Эти ресурсы создаются в том же пространстве имен, что и исходная нагрузка, а их привязка к родительскому объекту Kubernetes реализуется через поле ownerReference. Имя отчета формируется по шаблону <тип рабочей нагрузки>-<имя рабочей нагрузки>-<имя контейнера>.

Пример:

Ресурс SbomReport представляет собой инвентаризационную ведомость программного обеспечения (Software Bill of Materials — SBOM) для контейнерного образа, используемого в рабочих нагрузках Kubernetes. Отчет содержит исчерпывающий перечень всех программных компонентов, обнаруженных внутри образа, включая пакеты операционной системы и зависимости приложений. Данная информация необходима для анализа содержимого образа, проведения аудита безопасности и подтверждения соответствия требованиям вендоров и регуляторов.

При сканировании мультиконтейнерных подов operator-trivy генерирует отдельный экземпляр SbomReport для каждого контейнера. Эти ресурсы создаются в том же пространстве имен, что и исходная нагрузка, а их привязка к родительскому объекту Kubernetes реализуется через поле ownerReference. Имя отчета формируется по шаблону <тип рабочей нагрузки>-<имя рабочей нагрузки>-<имя контейнера>.

Пример:

Ресурс RbacAssessmentReport аккумулирует результаты аудита конфигурации ролевой модели доступа (RBAC) в кластере Kubernetes. Отчет формируется с использованием инструментов статического анализа, таких как Trivy, и содержит выводы проверок, направленных на выявление нарушений политик безопасности. В частности, анализ позволяет обнаружить роли (как на уровне пространств имен — Role, так и на уровне кластера — ClusterRole), которые:

• предоставляют избыточные привилегии (например, неограниченный доступ к секретам во всех API-группах);
• не соответствуют принципу минимально необходимых прав (least privilege).

Каждый экземпляр RbacAssessmentReport привязан к конкретной роли и размещается в том же пространстве имен, что и проверяемый объект (для ClusterRole отчет создается в неймспейсе по умолчанию или в соответствии с логикой оператора). Имя ресурса формируется по шаблону -<имя_роли>.

Пример:

Ресурс ClusterComplianceReport предназначен для агрегации данных о соответствии кластера Kubernetes требованиям безопасности. В текущей реализации основной областью проверки является CIS Kubernetes Benchmark — стандартизированный набор рекомендаций по безопасной конфигурации компонентов Kubernetes.

Отчет имеет двухкомпонентную структуру:

• spec.compliance.controls - определяет набор контролируемых критериев и параметров проверки;
• status - содержит фактические результаты выполнения проверок, соответствующих заданным в спецификации критериям. Итоговые данные формируются путем консолидации информации от всех интегрированных сканеров безопасности, работающих в кластере.

Пример:

Deckhouse Kubernetes Platform (DKP) предоставляет встроенные средства управления TLS-сертификатами, упрощающие настройку и управление шифрованием трафика в приложениях, работающих в кластере.

На этой странице описаны следующие аспекты использования сертификатов в DKP:

• как вручную заказывать TLS-сертификаты с помощью ресурсов Certificate и ClusterIssuer;
• как безопасно хранить и использовать учётные данные для доступа к удостоверяющим центрам (CA);
• как автоматически получать сертификаты с помощью аннотации tls-acme в ресурсах Ingress.

• Чтобы вывести список всех сертификатов в кластере, используйте следующую команду:

Чтобы заказать выпуск сертификата letsencrypt, выполните следующие шаги:

1. Создайте ресурс Certificate, опираясь на документацию cert-manager. Сверяйтесь с примером ниже:

2. Модуль cert-manager автоматически запустит проверку владения доменом (challenge) с использованием метода, указанного в ресурсе ClusterIssuer — например, HTTP-01 или DNS-01.

3. Модуль cert-manager автоматически создаст временный ресурс Ingress для проверки владения доменом. Временный ресурс не влияет на работу основного Ingress-ресурса.

4. После успешной проверки выпущенный сертификат будет сохранён в Secret, указанный в поле secretName.

1. Получите GlobalAPIKey и Email:

• зайдите на страницу dash.cloudflare.com/profile;
• ваша почта указана наверху под Email Address;
• для просмотра API-ключа нажмите View напротив Global API Key внизу страницы.

2. Отредактируйте настройки модуля cert-manager, добавив следующую секцию:

или указав API-токен вместо ключа (рекомендуемый вариант):

После этого DKP автоматически создаст ClusterIssuer и Secret для Cloudflare в пространстве имён d8-cert-manager.

3. Создайте ресурс Certificate с проверкой с помощью провайдера Cloudflare. Данная возможность появится только при указании настройки cloudflareGlobalAPIKey и cloudflareEmail в DKP:

4. Создайте ресурс Ingress:

1. Создайте пользователя с необходимыми правами:

• зайдите на страницу управления политиками и создайте политику со следующими правами:

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

2. Отредактируйте настройки модуля cert-manager, добавив следующую секцию:

После этого Deckhouse автоматически создаст ClusterIssuer и Secret для Route53 в пространстве имён d8-cert-manager.

3. Создайте ресурс Certificate с проверкой с помощью провайдера Route53. Данная возможность появится только при указании настроек route53AccessKeyID и route53SecretAccessKey в DKP:

1. Создайте ServiceAccount с необходимой ролью:

• зайдите на страницу управления политиками;
• выберите нужный проект и создайте ServiceAccount с желаемым названием, например dns01-solver;
• зайдите в созданный ServiceAccount и создайте ключ, нажав на Добавить ключ. Будет скачан JSON-файл с данными ключа;
• закодируйте полученный файл в строку формата Base64:

2. Сохраните полученную Base64-строку в параметре cloudDNSServiceAccount.

После этого Deckhouse автоматически создаст ClusterIssuer и Secret для CloudDNS в пространстве имён d8-cert-manager.

3. Создайте ресурс Certificate с валидацией через CloudDNS:

Чтобы заказать самоподписанный сертификат, укажите selfsigned в качестве имени издателя в поле issuerRef.name:

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

Важно придерживаться следующих правил:

1. Указывать доменные имена в поле SAN (Subject Alternative Name).

Поле SAN является более современным и распространенным методом указания доменных имен, на которые распространяется сертификат. Некоторые сервисы на данный момент уже не рассматривают поле CN (Common Name) как источник для доменных имен.

2, Корректно заполнять поля keyUsage, basicConstraints, extendedKeyUsage, а именно:

• basicConstraints = CA:FALSE

Данное поле определяет, относится ли сертификат к конечному пользователю (end-entity certificate) или к центру сертификации (CA certificate). CA-сертификат не может использоваться в качестве сертификата сервиса.

• keyUsage = digitalSignature, keyEncipherment

Поле keyUsage ограничивает допустимые сценарии использования данного ключа:

• digitalSignature — позволяет использовать ключ для подписи цифровых сообщений и обеспечения целостности соединения.
• keyEncipherment — позволяет использовать ключ для шифрования других ключей, что необходимо для безопасного обмена данными с помощью TLS (Transport Layer Security).
• extendedKeyUsage = serverAuth

Поле extendedKeyUsage уточняет дополнительные сценарии использования ключа, которые могут требоваться конкретными протоколами или приложениями:

• serverAuth — указывает, что сертификат предназначен для использования на сервере для аутентификации сервера перед клиентом в процессе установления защищенного соединения.

Также рекомендуется:

1. Издать сертификат на срок не более 1 года (365 дней).

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

2. Использовать стойкие криптографические алгоритмы, например, алгоритмы на основе эллиптических кривых (в т.ч. prime256v1).

Алгоритмы на основе эллиптических кривых (ECC) предоставляют высокий уровень безопасности при меньшем размере ключа по сравнению с традиционными методами, такими как RSA. Это делает сертификаты более эффективными по производительности и безопасными в долгосрочной перспективе.

3. Не указывать домены в поле CN (Common Name).

Исторически поле CN использовалось для указания основного доменного имени, для которого выдается сертификат. Однако современные стандарты, такие как RFC 2818, рекомендуют использовать поле SAN (Subject Alternative Name) для этой цели. Если сертификат распространяется на несколько доменных имен, указанных в поле SAN, то при дополнительном указании одного из доменов в CN в некоторых сервисах может возникнуть ошибка валидации при обращении к домену, не указанному в CN. Если указывать в CN информацию, не относящуюся напрямую к доменным именам (например, идентификатор или имя сервиса), то сертификат также будет распространяться на эти имена, что может быть использовано для вредоносных целей.

Для генерации сертификата воспользуемся утилитой openssl.

Заполните конфигурационный файл cert.cnf:

2. Сгенерируйте ключ на основе эллиптических кривых:

3. Создайте запрос на сертификат:

4. Сгенерируйте самоподписанный сертификат:

Если вы не хотите хранить учётные данные в конфигурации DKP, можно создать отдельный Secret и ссылаться на него в ресурсе ClusterIssuer.

Для этого выполните следующее:

1. Создайте Secret с ключом доступа:

2. Создайте ресурс ClusterIssuer со ссылкой на этот Secret:

3. Закажите сертификаты как обычно, используя созданный ClusterIssuer:

DKP поддерживает аннотацию kubernetes.io/tls-acme: "true" в ресурсах Ingress. Компонент cert-manager-ingress-shim следит за появлением аннотации и автоматически создаёт ресурсы Certificate в тех же пространствах имён, что и Ingress-ресурсы.

Пример конфигурации ресурса Ingress с аннотацией: