Deckhouse Development Portal (DDP, портал) предоставляет набор встроенных механизмов безопасности, обеспечивающих контроль доступа, защиту учётных данных и аудит действий пользователей при работе с порталом.
Аутентификация
Аутентификация пользователей в DDP выполняется с использованием внешнего сервиса Dex, развернутого в составе Deckhouse Platform.
Dex обеспечивает интеграцию с внешними провайдерами аутентификации (Keycloak, LDAP и другими) через стандартные протоколы OIDC и LDAP. DDP Backend использует ключи подписи, получаемые от Dex, для проверки JWT-токенов и аутентификации запросов к API. Настройка выполняется на стороне Deckhouse Platform, дополнительная настройка в DDP не требуется.
Ролевая модель (RBAC)
В DDP реализована ролевая модель доступа, обеспечивающая разграничение прав пользователей и контроль операций, выполняемых в портале.
Модель поддерживает иерархию ролей и проверку разрешений на уровне супер-администратора, глобальных ролей, ролей ресурсов и ролей сущностей. Подробнее — в документации по ролевой модели.
Имперсонация
DDP позволяет пользователю с разрешением impersonate:users временно работать в интерфейсе от имени другого пользователя для проверки прав доступа и диагностики. Сессия ограничена по времени; операции с учётными данными и секретами целевого пользователя в этом режиме недоступны.
Подробнее — в документации по имперсонации.
Учётные данные
DDP обеспечивает централизованное и безопасное хранение учётных данных, используемых для интеграции с внешними системами и сервисами. Хранение и обработка учётных данных выполняются на стороне DDP Backend с использованием базы данных PostgreSQL.
Перед сохранением в базе данных учётные данные шифруются с применением алгоритма AES-GCM. Расшифровка выполняется DDP Backend только в момент использования учётных данных в действиях, источниках данных или виджетах. Подробнее — в документации по учётным данным.
Ротация ключа шифрования
При смене ключа шифрования (параметр модуля security.secretKey) DDP позволяет перешифровать все связанные данные из веб-интерфейса, не теряя учётные данные пользователей, секреты Vault и другие зашифрованные значения. Операция доступна пользователям с разрешением rotate:encryption-key.
Подробнее — в документации по ротации ключа шифрования.
Доверенные сертификаты
DDP позволяет добавлять в хранилище корневые и промежуточные сертификаты (CA) или сертификаты серверов. Они используются при проверке TLS в исходящих HTTPS-запросах к внешним сервисам (в действиях, виджетах, источниках данных и др.).
Управление доверенными сертификатами осуществляется через веб-интерфейс в разделе «Администрирование» → «Доверенные сертификаты». Подробнее — в документации по доверенным сертификатам.
Аудит-логи
Аудит-логи предназначены для регистрации действий пользователей и контроля операций, выполняемых через API портала. Формирование аудит-логов выполняется на стороне DDP Backend.
Такие логи создаются автоматически для HTTP-запросов к API, кроме запросов GET и нескольких запросов, перечисленных в документации по аудит-логам. Каждая запись содержит информацию о пользователе, IP-адресе клиента, эндпоинте, HTTP-методе и статусе ответа.
Аудит-логи сохраняются в базе данных PostgreSQL и доступны для просмотра через веб-интерфейс портала. Также возможна выгрузка аудит-логов в CSV из интерфейса портала. Подробнее — в документации по аудит-логам.
HTTP-заголовки безопасности
Для защиты веб-интерфейса и API DDP используются стандартные HTTP-заголовки безопасности. Их формирование и применение выполняется на стороне DDP Frontend и DDP Backend. Заголовки направлены на снижение рисков XSS-атак и clickjacking, предотвращение MIME-sniffing, контроль передачи информации о реферере, а также на принудительное использование защищённого соединения HTTPS.
В портале применяются следующие HTTP-заголовки безопасности:
- Content Security Policy (CSP).
- X-Frame-Options.
- X-Content-Type-Options.
- X-XSS-Protection.
- Referrer-Policy.
- Permissions-Policy.
- Strict-Transport-Security (HSTS). DDP Backend добавляет этот заголовок, только если TLS-соединение завершается на самом DDP Backend. При стандартной установке TLS-соединение завершается на Ingress-контроллере, поэтому HSTS настраивается на нём.
Заголовки настраиваются в параметре security.headers модуля development-platform: в ModuleConfig development-platform (spec.settings.security.headers) или в настройках модуля в веб-интерфейсе Deckhouse Platform. Подробнее — в документации по HTTP-заголовкам безопасности.