Kubernetes Deckhouse с сертификатом ФСТЭК: российский enterprise K8s

Deckhouse Kubernetes Platform — первое российское K8s-решение, официально сертифицированное ФСТЭК (сертификат № 4860 от 04.10.2024). Для госсектора и банков это единственный легальный способ запускать контейнеры в production. Реальный кейс: внедрение Deckhouse в одном региональном банке — 50 нод, больше 200 микросервисов, и вся эта система полностью соответствует строжайшим требованиям Центробанка РФ.

Deckhouse vs vanilla Kubernetes: ключевые отличия

Production кейс: региональный банк

Разбираем архитектуру Deckhouse для банковской инфраструктуры:

# Deckhouse cluster configuration
apiVersion: deckhouse.io/v1
kind: ClusterConfiguration
metadata:
  name: bank-production
clusterType: Static
podSubnetCIDR: "10.111.0.0/16"
serviceSubnetCIDR: "10.222.0.0/16"
kubernetesVersion: "1.28"
clusterDomain: "cluster.local"
---
# ФСТЭК compliance modules
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: security-policies
spec:
  enabled: true
  settings:
    enforcementMode: "strict"
    podSecurityStandards: "restricted"
    networkPolicies: "deny-all-default"
    auditPolicy: "fstec-compliant"

Безопасность по стандартам ФСТЭК

• Мандатное разграничение доступа — интеграция с МЭ «Заря»
• Аудит всех операций — k8s audit + Deckhouse events
• Шифрование данных — etcd encryption + pod-to-pod TLS
• Network isolation — Calico with ФСТЭК policies
• Container security — image scanning + runtime protection

Интеграция с российскими SIEM

# MaxPatrol SIEM integration
apiVersion: deckhouse.io/v1alpha1
kind: DeckHouseConfig
metadata:
  name: siem-integration
spec:
  auditPolicy:
    rules:
    - level: "RequestResponse"
      namespaces: ["production", "critical"]
      verbs: ["create", "update", "delete"]
      resources:
      - group: ""
        resources: ["pods", "services", "secrets"]

    webhook:
      config:
        endpoint: "https://maxpatrol.bank.local/api/k8s-events"
        headers:
          Authorization: "Bearer ${SIEM_TOKEN}"

TCO и лицензирование

А теперь о главном для enterprise: стоимость Deckhouse на 3 года.

Migration с vanilla Kubernetes

# Migration strategy
# 1. Backup existing workloads
kubectl get all --all-namespaces -o yaml > k8s-backup.yaml

# 2. Install Deckhouse
curl -L https://deckhouse.io/install.sh | bash -s -- \
  --cluster-type=existing \
  --config=deckhouse-config.yaml

# 3. Migrate workloads gradually
# Namespace-by-namespace approach
kubectl label namespace production deckhouse.io/migrated=true

# 4. Enable ФСТЭК modules
kubectl apply -f fstec-compliance.yaml

Production опыт: что работает хорошо

• Автоматические обновления — zero-downtime K8s upgrades
• Russian support — техподдержка на русском языке
• Compliance reporting — готовые отчеты для ФСТЭК аудита
• Integrated stack — мониторинг, логи, алерты из коробки
• Multi-cloud — работает в Yandex.Cloud, VK Cloud, on-premises

Что может быть лучше

• Документация — не хватает enterprise use cases
• Vendor lock-in — сложно мигрировать обратно на vanilla K8s
• Экосистема — меньше community modules vs Helm charts
• Цена — дороже чем DIY подход

Что именно сертифицировано: редакция CSE и требования ФСТЭК

Первое, что я проверяю перед любым проектом с «сертифицированным Kubernetes», — какая редакция стоит у заказчика. Сертификат выдан не на Deckhouse вообще, а на конкретную сборку. По данным страницы безопасности на сайте вендора, действует сертификат ФСТЭК России №4860 от 04.10.2024 на ПО Deckhouse Platform CSE (Certified Security Edition). Продукт внесён в реестр российского ПО, запись №12338 от 21.12.2021.

Против каких требований проводилась сертификация:

• требования к средствам контейнеризации (приказ ФСТЭК России №118 от 4 июля 2022 г.) — 4-й класс защиты;
• требования к средствам виртуализации (приказ ФСТЭК России №187 от 27 октября 2022 г.) — 4-й класс защиты;
• требования к уровням доверия (приказ ФСТЭК России №76 от 2 июня 2020 г.) — 4-й уровень доверия.

Вендор указывает, что с этим сертификатом платформу можно применять на значимых объектах КИИ до 1-й категории значимости включительно (приказ ФСТЭК №239), в информационных системах персональных данных до 1-го уровня защищённости включительно (приказ ФСТЭК №21), в ГИС до 1-го класса защищённости (приказ ФСТЭК №117 от 11 апреля 2025 г.) и в АСУ ТП до 1-го класса (приказ ФСТЭК №31).

Отсюда практический вывод. Если в кластере работает редакция Community (CE) или обычная Enterprise, никакого сертификата у этой установки нет, как бы ни назывался продукт в договоре. Для аттестации нужна именно сертифицированная сборка CSE, полученная от вендора. В документации с версии 1.76 платформа переименована в Deckhouse Platform, а редакции получили новые имена: Open/CE, Core, BE, SE, SE+, Ultimate/EE, Certified Core (CSE Lite) и Certified Pro (CSE Pro). Я всегда сверяю название редакции в лицензии со списком из документации, чтобы не было путаницы.

Установка: как это выглядит руками

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

docker login -u license-token registry.deckhouse.ru

docker run --pull=always -it \
  -v "$PWD/config.yml:/config.yml" \
  -v "$HOME/.ssh/:/tmp/.ssh/" \
  registry.deckhouse.ru/deckhouse/ee/install:stable bash

# внутри контейнера — развёртывание нового кластера
dhctl bootstrap --ssh-user=<user> \
  --ssh-agent-private-keys=/tmp/.ssh/id_ed25519 \
  --config=/config.yml

В адресе образа вместо ee подставляется код редакции (ce — Community Edition), а в теге — канал: alpha, beta, early-access, stable или rock-solid. Для установки в уже существующий кластер документация предписывает другую команду — dhctl bootstrap-phase install-deckhouse, а не bootstrap. Полный список ключей выводит dhctl bootstrap -h.

Перед запуском я проверяю три вещи: ОС узлов есть в списке поддерживаемых вендором, на все узлы есть вход по SSH-ключу, а сетевые доступы между узлами открыты по таблице из раздела о сетевом взаимодействии компонентов. Установщик сам выполняет предварительные проверки и останавливается, если что-то не так, но лучше не доводить до этого на площадке заказчика.

Обновления: каналы, окна и ручное подтверждение

Автоматические обновления — сильная сторона Deckhouse и одновременно главный риск для регулируемых систем. Поэтому первым делом после установки я настраиваю модуль deckhouse. Каналы обновлений в порядке роста стабильности: Alpha, Beta, EarlyAccess, Stable, RockSolid. Для продуктивных кластеров я выбираю Stable или RockSolid, для тестового стенда — EarlyAccess, чтобы видеть новые версии раньше.

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: deckhouse
spec:
  version: 1
  settings:
    releaseChannel: Stable
    update:
      mode: AutoPatch
      windows:
        - from: "20:00"
          to: "23:00"
          days: ["Sat", "Sun"]

Режим update.mode принимает три значения:

• Auto — автоматически ставятся и минорные, и патч-версии;
• AutoPatch — патч-версии (например, v1.70.1 → v1.70.2) ставятся сами, а для минорной версии (v1.69 → v1.70) нужно подтверждение;
• Manual — подтверждение нужно для любого обновления: поле approved: true в ресурсе DeckhouseRelease.

Время в окнах обновлений задаётся в UTC, а не в местном часовом поясе. Об этом легко забыть: окно «с 20:00 до 23:00» в конфигурации — это 23:00–02:00 по Москве. В сертифицированной среде я ставлю Manual или AutoPatch: любое изменение версии должно проходить через процедуру управления изменениями, а не случаться ночью само.

Модули безопасности, которые я включаю первыми

Список «безопасность из коробки» в маркетинговых материалах выглядит длинным, но на практике работу делают три модуля. Важно учитывать редакцию: runtime-audit-engine и operator-trivy доступны в Ultimate/EE и сертифицированных редакциях, а admission-policy-engine в младших редакциях работает с ограничениями.

admission-policy-engine проверяет манифесты в момент создания и изменения объектов. Политики делятся на три категории: Pod Security Standards, операционные политики (например, разрешённые префиксы образов, обязательные пробы) и политики безопасности (доступ к IPC и PID хоста, привилегии контейнеров). Политика PSS включается меткой на пространстве имён, режим — второй меткой:

kubectl label ns production security.deckhouse.io/pod-policy=restricted
kubectl label ns production security.deckhouse.io/pod-policy-action=warn

Режимы: deny запрещает запуск, warn пускает с предупреждением, dryrun только фиксирует нарушения в отчётах. На существующих приложениях я начинаю с dryrun, разбираю нарушения и лишь потом перевожу в deny. Системные пространства имён модуль не трогает.

operator-trivy сканирует образы на известные CVE, в том числе по базам Astra Linux, ALT Linux и РЕД ОС, и проверяет кластер на соответствие CIS Kubernetes Benchmark. Сканируются пространства имён с меткой security-scanning.deckhouse.io/enabled=""; если ни одной такой нет — только default. Проверка запускается раз в 24 часа и при появлении новых образов, результаты видны в Grafana.

runtime-audit-engine построен на Falco: собирает события ядра через eBPF и аудит API Kubernetes и ловит оболочки, запущенные внутри контейнеров, привилегированные контейнеры, монтирование /proc, попытки прочитать /etc/shadow. Его события я отправляю в SIEM заказчика — именно эти записи потом просят показать при проверке.

Заключение: когда выбирать Deckhouse

Обязательно для:

• Госсектора (ФСТЭК обязательно)
• Банков (требования ЦБ РФ)
• Критичных систем с высокими SLA

Рассмотреть для:

• Команд без глубокой K8s экспертизы
• Проектов с жесткими deadline
• Enterprise с budget на поддержку

Deckhouse — это полностью зрелое российское решение, идеальное для корпоративного Kubernetes. А вот сертификат ФСТЭК делает его по-настоящему уникальным: это теперь единственный вариант для всех регулируемых отраслей.