en

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

Чтобы повысить защищенность кластера и развернутых в нем приложений, мы используем проверенные Open Source-инструменты и лучшие практики DevSecOps. В платформе реализованы продвинутые механизмы аутентификации и авторизации, шифрование, аудит и другие важные функции. Все инструменты и политики преднастроены: вы разворачиваете Deckhouse — и получаете уже защищенный кластер.

Главные особенности

CIS Benchmarks

Deckhouse соответствует рекомендациям CIS Kubernetes Benchmark recommendations*. Это реализовано на уровне компонентов и платформы в целом. Например, можно указывать сетевые привязки только к нужным интерфейсам, запретить анонимный доступ, использовать сертификаты, права на файлы и каталоги.

Также для проверки соответствия CIS Benchmarks в каждом кластере Deckhouse запускаются автоматические тесты. Отчеты с результатами выводятся в дашборде Grafana.

* CIS Kubernetes Benchmark — набор рекомендаций по созданию надежной системы безопасности для ПО на базе Kubernetes.

SELinux

Security-Enhanced Linux (SELinux)* — стандарт для защиты Linux-дистрибутивов. В дистрибутивах, которые используются в Deckhouse, можно активировать принудительное включение режима SELinux.

* SELinux определяет политики доступа к приложениям, процессам и файлам.

PCI SSC

Deckhouse соответствует большинству рекомендаций PCI Security Standards Council (PCI SSC)*. Платформа надежно защищена от угроз, актуальных для платежных систем, в которых применяются контейнерные технологии. Для оценки защищенности Deckhouse мы использовали «Руководство по контейнерам и инструментам оркестровки контейнеров».

Скачать отчет

* PCI SSC — организация, которая помогает разрабатывать, применять и улучшать стандарты безопасности для защиты платежных систем.

ФСТЭК

В настоящий момент Deckhouse проходит сертификационные испытания на соответствие:

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

Инструменты и лучшие практики

Deckhouse предоставляет продуманную безопасность «из коробки».

  • Федеративный провайдер аутентификации с возможностью подключения любых внешних служб каталогов. Управляйте актуальным каталогом пользователей там, где вам привычно.
  • Сквозная авторизация на основе ролей, которая расширяет функциональность стандартного механизма RBAC. Гибкое централизованное управление доступами. 7 предустановленных ролей плюс возможность создания новых.
  • Продвинутые сетевые политики на базе Cilium.
  • Аудит событий Kubernetes для учета операций в кластере и анализа ошибок.

Сборка компонентов

Принципы работы с образами

  • Docker-образы для всех компонентов платформы можно скачивать только из репозитория Deckhouse.
  • Из оригинальных образов от разработчиков ПО используются только нужные бинарные файлы.
  • Все зависимости на оригинальные образы, а также SHA256-digest образа строго прописаны. Результирующий образ собирается из нашего базового образа.
  • Для сборки базового образа почти всегда используем Alpine — самый безопасный дистрибутив Linux.
  • Регулярно обновляем компоненты Deckhouse и Kubernetes.

Отбор и тестирование компонентов

  • Тщательно выбираем софтИспользуем только те решения, которые доказали свою надежность в наших проектах и в Open Source-сообществе.
  • Большинство проверок автоматизированы, за это отвечают линтерыНапример, они отслеживают корректную конфигурацию Dockerfile’ов и запрещают использовать сторонние образы.
  • Сборка в CI ежедневно сканируется на CVEОтчет о сканировании отправляется разработчикам. Разбираем инциденты уровня Sn и выше в течение 3 часов, уровня Sn-Sk — в течение 24 часов.

Настройка и взаимодействие компонентов

Надежная иерархия прав доступа

  • Каждый компонент запускается с минимальными правами доступа в Kubernetes, которые достаточны для его работы (минимальный RBAC).
  • Компоненты не запускаются под root-правами. Исключения явно прописаны в списке разрешений.
  • Корневая файловая система открыта только на чтение, за исключением отдельных директорий.
  • Ни один компонент Deckhouse не открывает локальный порт без TLS-шифрования и аутентификации.

Авторизация (минимальный RBAC)

  • Линтеры проверяют, что RBAC-права описаны в определенном файле каждого модуля Deckhouse явно и однозначно. Это обеспечивает единую точку контроля.
  • Названия для Service Accounts, Roles, RoleBindings и т. п. строго регламентированы — это защищает от человеческих ошибок.
  • Аутентификация между компонентами кластера всегда проводится одним из двух способов: через TLS или с помощью bearer-токенов. Авторизация — через механизмы Kubernetes (SubjectAccessReview).

Roadmap

Мы постоянно повышаем уровень безопасности Deckhouse.
За планом по добавлению новых функций и улучшению существующих можно следить в нашем roadmap.

Нашли уязвимость?

Если вы нашли уязвимость в Deckhouse Kubernetes Platform, пожалуйста,сообщите о ней, заполнив информацию в форме обратной связи.
Мы рассмотрим обращение и при необходимости свяжемся с вами, чтобы получить дополнительную информацию и как можно скорее исправить проблему.

Сообщить