Безопасность Deckhouse
Чтобы повысить защищенность кластера и развернутых в нем приложений, мы используем проверенные Open Source-инструменты и лучшие практики DevSecOps. В платформе реализованы продвинутые механизмы аутентификации и авторизации, безопасное взаимодействие компонентов, шифрование, аудит и другие важные функции.
CIS Benchmarks
Deckhouse соответствует рекомендациям CIS Kubernetes Benchmark*. Это реализовано на уровне компонентов и платформы в целом. Например, можно указывать сетевые привязки только к нужным интерфейсам, запретить анонимный доступ, использовать сертификаты, права на файлы и каталоги.
* 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 предоставляет набор решений для безопасной аутентификации, авторизации, управления сетевыми политиками, заказа 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 может подключаться к портам мониторинга.