Распределенное Java-приложение внутри Docker Swarm - PullRequest
0 голосов
/ 15 октября 2018

Моя цель - запустить распределенный кластер NIFI внутри док-контейнеров на Docker Swarm.Конфигурации, которые я сделал для официального образа докера NIFI, работают так, что я могу запустить кластер.

Для кластера я использую одну службу, и каждая реплика является отдельным экземпляром NIFI.Поскольку это работает, я хочу продолжить с безопасностью сейчас.Я начал с применения публично подписанного сертификата с подстановочными знаками к Java-приложению, используя секрет (передача хранилища доверия и ключей).На мой взгляд, это может быть осуществимым подходом для большинства распределенных Java-приложений.Но с NIFI у меня теперь возникла проблема, что сам NIFI не поддерживает групповые сертификаты.

В настоящее время я думаю о подходе к запуску кластера таким образом, чтобы каждый контейнер имел свой собственный сертификат.Моя текущая идея состоит в том, чтобы запускать самозаверяющие сертификаты внутри контейнера с помощью внутреннего внутреннего СА, которому доверяют JVM NIFI.Поскольку я не на 100% уверен, что это правильный подход к этой проблеме, я благодарен за подсказки и идеи.
NIFI использует некоторые порты для связи, а запросы отправляются с использованием протокола HTTP / S.Сам NIFI работает как Java-приложение на узлах / контейнерах.

1 Ответ

0 голосов
/ 18 октября 2018

Apache NiFi предоставляет TLS Toolkit , который автоматизирует большую часть этого процесса для вас.Он может запускать временный или долговечный внутренний центр сертификации (CA), который генерирует внутренние ключи и использует их для создания самозаверяющего сертификата CA и подписания входящих запросов на подпись сертификата (CSR).Каждый подключенный узел может обратиться к службе CA и установить правильно настроенный сертификат в своем хранилище ключей и хранилище доверенных сертификатов и автоматически заполнить файл nifi.properties местоположениями и паролями для этих файлов с помощью одного вызова командной строки.Это можно настроить для запуска во время развертывания с помощью Dockerfile, сценария Ruby / Python / shell и т. Д.

Сигнатура HMAC / SHA-256 рассчитывается по SPKI с использованием значения токена общего секретного ключа, чтобы обеспечить мошенническое / вредоносное действие.услуги не получают выданные сертификаты.Все сертификаты будут подписаны одним и тем же сертификатом CA, и он уже заполнен в хранилище доверенных сертификатов, поэтому каждый узел в кластере будет доверять другим.Запрошенный CN также заполняется в записях SAN, и поддерживаются дополнительные записи SAN, так что это соответствует RFC 6125.

Как отмечалось выше, подстановочные сертификаты не поддерживаются и не рекомендуются по целому ряду причин ( некоторые перечислены здесь ), а также потому, что более безопасное развертывание уникальных сертификатов упрощается с помощьюпредоставленный инструментарий.Предпринимаются постоянные усилия ( NIFI-5443 , NIFI-5398 ) по изменению некоторых внутренних связей кластера, чтобы они были устойчивыми перед лицом подстановочных сертификатов, но в настоящее время они недоступны.

...