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

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

Инструменты

Deckhouse предоставляет набор решений для безопасной аутентификации, авторизации, управления сетевыми политиками, заказа TLS-сертификатов и не только.

Федеративный провайдер аутентификации

  • Предустановленный федеративный провайдер аутентификации на базе Dex (Identity Provider, IdP).
  • Интегрирован с Kubernetes и всеми служебными компонентами.
  • Возможна интеграция с приложением, если оно поддерживает OIDC.
  • Оператор oauth2-proxy поддерживает удобное взаимодействие с Ingress-контроллером.
  • Можно создавать пользователей прямо в кластере, а также подключать пользователей внешних систем аутентификации: GitHub, GitLab, OIDC, LDAP.

Авторизация
упрощенный RBAC

  • Deckhouse предлагает более простую и удобную версию RBAC Kubernetes — 7 готовых ролей, которые подходят для любых практических сценариев. Это снижает вероятность ошибки и облегчает настройку политик авторизации.
  • Если необходимо, можно расширить количество ролей через обычные средства RBAC Kubernetes.

А также

  • Модуль управления сетевыми политиками. Простая и надежная система с правилами, которые не зависят от типа инсталляции и используемого CNI.
  • Аудит событий Kubernetes для учета операций в кластере и анализа ошибок.
  • Модуль cert-manager. Поддерживает заказ сторонних TLS-сертификатов и выпуск самоподписанных. Актуализирует и автоматически перевыпускает сертификаты.

Скоро

  • Multitenancy
  • Интеграция с HashiCorp Vault
  • Интеграция с OpenPolicyAgent

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

Правила

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

Как это реализовано

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

Пример Dockerfile для модуля kube-dns*

# Based on https://github.com/coredns/coredns/blob/master/Dockerfile
ARG BASE_ALPINE
FROM coredns/coredns:1.6.9@sha256:40ee1b708e20e3a6b8e04ccd8b6b3dd8fd25343eab27c37154946f232649ae21 as artifact

FROM $BASE_ALPINE
COPY --from=artifact /coredns /coredns
ENTRYPOINT [ "/coredns" ]

* Модуль устанавливает компоненты CoreDNS для управления DNS в кластере Kubernetes.

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

Правила

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

Авторизация
упрощенный RBAC

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

Пример: для мониторинга в кластере используется Prometheus. Он собирает данные со всех компонентов. У каждого из компонентов есть порт для подключения сервиса мониторинга. При подключении к этому порту Prometheus использует индивидуальный SSL-сертификат.

Когда от Prometheus поступает запрос, компонент проводит аутентификацию — проверяет, что сертификат Prometheus подписан Certificate Authority Kubernetes; после этого — авторизацию, запрашивая SubjectAccessReview. Такой механизм гарантирует, что только Prometheus может подключаться к портам мониторинга.

Мы используем cookies
Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie. Подробнее