Обновления DKP Certified Security Edition

DKP CSE v1.67

Описание обновления

Основные изменения

Поддерживаемые версии Kubernetes — 1.27 и 1.29.
Контроллер Ingress Nginx версии 1.10.
Grafana версии 10.
Удалены модули kube-proxy и cni-flannel. Если в вашем ĸластере используется cni-flannel, то необходимо сначала перейти на cni-cilium согласно инструкции и тольĸо после этого выполнить обновление.
Добавлены новые модули и компоненты (см. раздел Новые модули и компоненты)
DKP CSE теперь самостоятельно назначает StorageClass, который используется в кластере по умолчанию, исходя из значения глобального параметра defaultClusterStorageClass. Назначить используемый по умолчанию StorageClass вручную с помощью аннотации теперь нельзя.
Появилась возможность указывать дополнительные домены приложения при настройке аутентификации через секцию параметров additionalApplications в DexAuthenticator. Это позволяет использовать только один экземпляр dex-authenticator, выполняющего функции аутентификации, для всех доменов приложения.
В модуле cni-cilium реализован DHCP-сервер на базе eBPF для подов.
Модуль MetalLB был полностью переработан: расширена функциональность и повышена отказоустойчивость при работе в режиме L2-балансировщика. Добавлена возможность назначения сервису нескольких IP-адресов, которые равномерно распределяются между узлами кластера и автоматически мигрируют между ними в случае выхода узлов из строя.
В модуле multitenancy-manager реализован режим высокой доступности.
Улучшена обработка многострочных логов (multiline) в log-shipper.
Улучшено логирование и обработка ошибок в установщике.

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

Устранены все CVE, известные на момент выхода DKP CSE.
Поддержка пользовательских CA-сертификатов для приватных registry.
Повышена безопасность пользовательских сессий в user-authn
Dashboard теперь работает только через HTTPS
Исправлены проблемы с потерей пакетов при использовании VXLAN (модуль cni-cilium)

Обратите внимание

Все модули будут автоматически перезапущены в процессе обновления.

Новые модули и компоненты

Подсистема «Кластер Kubernetes»

Модуль istio.
Модуль обеспечивает централизованное управление сетевым трафиком с возможностями взаимной аутентификации и шифрования трафика через Mutual TLS, авторизации доступа между сервисами, продвинутой маршрутизации и балансировки нагрузки, повышенной наблюдаемости с использованием инструментов для сбора и визуализации метрик и данных трассировки, а также организацию мульти-ЦОД кластеров и федерацию кластеров для стандартизированного доступа к сервисам.

Модуль cilium-hubble.
Модуль агрегирует данные и предоставляет их в визуализированном виде, чтобы улучшить мониторинг и управление сетевым стеком кластера.

Модуль namespace-configurator.
Модуль позволяет автоматически управлять аннотациями и метками пространств имен.

Подсистема Deckhouse

Модуль deckhouse-tools.
Модуль создает веб-интерфейс со ссылками на скачивание внутри кластера утилит командной строки под различные операционные системы.

Модуль console.
Модуль предоставляет веб-интерфейс для управления кластером и визуализации состояния системы, позволяя просматривать информацию о кластере, управлять модулями, узлами и тенантами, настраивать интеграцию с провайдерами аутентификации и Ingress-контроллерами, а также обеспечивает функции журналирования и мониторинга с настройкой метрик, оповещений и дашбордов.

Подсистема «Мониторинг»

Модуль extended-monitoring.
Модуль предоставляет расширенный сбор метрик и отправку алертов, включая мониторинг свободного места, доступности контейнерных образов, событий в Kubernetes, и истечения срока действия сертификатов, за счёт использования нескольких Prometheus-экспортёров.

Модуль monitoring-custom.
Модуль расширяет функциональность модуля prometheus для мониторинга приложений в кластере Kubernetes. Обеспечивает возможность настройки метрик с помощью специальных меток и аннотаций на Service или Pod.

Модуль monitoring-ping.
Модуль предназначен для мониторинга сетевого взаимодействия между узлами кластера, а также до любых внешних узлов.

Подсистема «Масштабирование и управление ресурсами»

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

Подсистема «Безопасность»

Модуль stronghold
Модуль предназначен для организации безопасного хранилища данных, управления жизненным циклом хранения данных. Реализует хранилище в формате key-value. Предоставляет доступ к хранилищу через веб-интерфейс и API.

Модуль secret-copier.
Модуль отвечает за копирование секретов (ресурс Secret), имеющих специальную метку, по всем пространствам имен кластера.

Модуль secrets-store-integration.
Модуль реализует высокоуровневый интерфейс работы с секретами из внешних хранилищ через CSI. Позволяет подключать секреты из внешних хранилищ в приложения в виде тома.

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

Подсистема «Хранение данных»

Модуль sds-node-configurator.
Модуль управляет локальным блочным хранилищем на базе LVM, обнаруживает блочные устройства на узлах, определяет состояние LVM volume group в кластере и отражает это состояние в объектах LVMVolumeGroup, а также обрабатывает объекты LVMVolumeGroupSet.

Модуль sds-local-volume.
Модуль предоставляет высокоуровневый интерфейс для работы с устройствами хранения и томами LVM, управляя ресурсами через компоненты для узлов и контроллеров CSI, расширяя возможности планировщика в учете свободного пространства и наличия VolumeGroup, и обеспечивая валидацию операций через вебхуки, без необходимости непосредственного взаимодействия с ресурсами StorageClass.

Закрытые уязвимости

CVE-2024-24557

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

HIGH

docker

CVE-2024-44337

Логическая ошибка, которая позволяла удаленно вызвать состояние отказа в обслуживании (DoS), предоставляя специально подобранные входные данные, которые вызывали бесконечный цикл, заставляя программу зависать и потреблять ресурсы бесконечно.

MEDIUM

markdown

CVE-2021-36156

В Loki значение заголовка X-Scope-OrgID используется для построения путей к файлам правил, и если оно создано для обхода каталога, то Loki пытается разобрать файл правил и включить часть его содержимого в сообщение об ошибке.

MEDIUM

loki

CVE-2024-35192

Если злоумышленнику удавалось заставить Trivy сканировать образы контейнеров из созданного вредоносного реестра, это могло привести к утечке учетных данных

MEDIUM

trivy

CVE-2021-6531

В Bootstrap обнаружена уязвимость, которая подвергает пользователей атакам межсайтового скриптинга (XSS)

MEDIUM

bootstrap

CVE-2023-40577

Злоумышленник, имеющий право выполнять POST-запросы к конечной точке /api/v1/alerts, может получить возможность выполнить произвольный JavaScript-код на пользователях Prometheus Alertmanager.

MEDIUM

alertmanager

Документация

Руководство пользователя icon

Руководство администратора icon

Контрольная сумма

Рекомендации по обновлению

Руководство по обновлению DKP CSE c 1.64 до 1.67

DKP CSE v1.64

Описание обновления

Основные изменения

Добавлен альтернативный способ управления сетью в кластере. Новый модуль cni-cilium, как и старый модуль cni-flannel, настраивает сетевую инфраструктуру в кластере и управляет ею. Новый модуль обеспечивает большую производительность (за счет использования eBPF) и дает возможность применять сетевые политики.
Добавлен кэширующий DNS-сервер. Новый модуль node-local-dns запускает на каждом узле кластера DNS-сервер, который ускоряет работу DNS.
Добавлен L2/BGP-балансировщик трафика. Новый модуль metallb дает возможность настроить балансировку TCP-трафика на узлы кластера, когда нет возможности использовать внешний балансировщик.
Добавлена функция изоляции проблемных узлов — fencing. Она позволяет кластеру быстрее реагировать на недоступность узла, снизить риск сбоя и потери данных, особенно в приложениях с сохранением состояния (Stateful-приложениях). При потере узлом связи с API-севером в течение минуты все поды узла удаляются, а сам узел удаляется из кластера. Функция настраивается в NodeGroup в секции параметров spec.fencing.
Режим высокой доступности для Deckhouse. В кластерах с более чем одним master-узлом ядро DKP работает по умолчанию в нескольких репликах. Режимом высокой доступности можно управлять глобально или на уровне модуля (параметр highAvailability).
Добавлена возможность автоматического вертикального масштабирования приложений. Новый модуль vertical-pod-autoscaler позволяет не выставлять точные параметры требуемых ресурсов в манифестах приложений, а вычислять их автоматически на основе данных модулей мониторинга.
Добавлена поддержка работы с хранилищами Ceph и NFS. Также добавлена возможность создания снимков состояния томов хранения данных Ceph и NFS (снапшотов) декларативным способом, с помощью ресурсов VolumeSnapshot. Функция, например, облегчает работы по резервному копированию или клонированию томов данных Ceph и NFS.
Добавлена функциональность работы с проектами (новый модуль multitenancy-manager). Проект описывается ресурсами ProjectTemplate (шаблон проекта) и Project (экземпляр проекта). В модуле предлагаются три преднастроенных шаблона проекта: «базовый», «безопасный» и «безопасный, с выделенными узлами». Подробнее об использовании проектов можно узнать в документации.
Добавлен агрегирующий прокси для метрик мониторинга (на базе promxy и mimir). Агрегирующий прокси позволяет использовать один источник данных в системе мониторинга, объединяя данные от всех реплик Prometheus.
Добавлен механизм декларативного управления статическими узлами. Реализующий эту функцию провайдер Cluster API Provider Static (CAPS) использует объекты StaticInstance, SSHCredentials и секцию параметров spec.staticInstances в объекте NodeGroup, чтобы настраивать сервер узла и подключить его к кластеру. Также провайдер CAPS отвечает за очистку сервера узла после отключения узла из кластера Kubernetes. Помимо этого, существует возможность перевода узлов под управление провайдера CAPS. Для этого нужно в соответствующем объекте StaticInstance установить аннотацию static.node.deckhouse.io/skip-bootstrap-phase: ""
Добавлена поддержка NGINX Ingress Controller 1.10 (возможна несовместимость директив на уровне configuration-snippet) и HTTP/3.
Добавлена возможность просмотра веб-версии документации DKP внутри кластера (модуль documentation).
Добавлена возможность реализации отказоустойчивого egress gateway. Для настройки используются ресурсы EgressGateway и EgressGatewayPolicy. Ресурс EgressGateway позволяет назначить группу узлов в качестве шлюзов для внешних запросов. Среди этих узлов выбирается активный, который и обрабатывает внешние запросы. Ресурс EgressGatewayPolicy используется для перенаправления внешних запросов приложений через настроенные шлюзы (доступно только при использовании модуля cni-cilium).
Добавлена возможность расширения планировщика внешними плагинами через вебхуки (ресурс KubeSchedulerWebhookConfiguration). Позволяет, например, настроить размещение подов приложений хранилища данных ближе к самим данным, использовать приоритет при выборе узла в зависимости от его состояния (сетевой нагрузки, состояния подсистемы хранения) и т. д.
Конфигурацию инсталлятора DKP можно разбивать на любое количество файлов, указывая их через множественное использование параметра --config. Инсталлятор сам определит нужный порядок применения ресурсов.
Дополнены предварительные проверки установщика, которые до начала установки сообщают о потенциальных проблемах установки DKP, таких как корректность данных подключения к container registry, наличие подключения по SSH и т. п.
Добавлены метрики мониторинга по группам узлов.
Добавлена возможность отправлять журналы приложений через сокет TCP или UDP. Возможные форматы сообщений: текст, JSON, CEF, Syslog.
На активный под контроллера DKP (d8-system/deckhouse) добавлена метка лидера (leader=true). Это позволяет удобнее выполнять команды в поде DKP, независимо от того, работает ли он в режиме высокой доступности или нет. Например: kubectl -n d8-system -l app=deckhouse,leader=true -c deckhouse logs
Пользователям запрещено создание пространств имён с префиксом d8- и kube-. Такие системные пространства имён может создавать только сам DKP.
В модуле runtime-audit-engine добавлена возможность управлять настройками VPA (параметр resourcesRequests). Порт хука валидации изменился с 9680 на 4227. Возможно, это потребует обновления правил firewall, если трафик к master-узлам кластера фильтруется. Появилась возможность отправлять логи в Graylog — добавлена поддержка кодека GELF (параметр spec.socket.encoding.codec)
Добавлена возможность скачивания утилиты Deckhouse CLI внутри кластера (новый модуль deckhouse-tools). Утилита Deckhouse CLI предназначена для более удобной работы с кластерами Deckhouse Kubernetes Platform в терминале.
Добавлена валидация полей электронной почты и пароля пользователя при его создании — эти поля обязательны к заполнению.
Добавлена возможность разрешать использование в конкретных пространствах имён только конкретных классов Ingress-контроллера (IngressClass) и конкретных классов хранения (StorageClass). Для этого нужно указать список классов Ingress-контроллера (параметр policies.ingressClassNames) и классов хранения (параметр policies.storageClassNames) в операционной политике кластера.

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

Общий рефакторинг процесса сборки.
Использование distroless-образов следующими модулями и компонентами: cni-cilium, ebpf_exporter, memcached (Prometheus).
Добавлена возможность управления разрешением на запуск подов с автоматическим монтированием токена сервисного аккаунта (параметр automountServiceAccountToken) в политике безопасности.
Используются более строгие права для файлов и папок конфигурации кластера и файлов и папок, создаваемых Deckhouse.

Обратите внимание

Изменился диапазон портов, используемый компонентами DKP. Теперь управлять сетевыми политиками проще, так как большинство портов входит в диапазон 4200–4299. Актуальный список используемых портов и информацию об их назначении можно найти в документации.
Все компоненты DKP будут перезапущены в процессе обновления на новую версию.