Использование Spring Cloud Config практически в Производстве на облаке? - PullRequest
0 голосов
/ 01 июля 2019

Я читал о сервере Spring Cloud Config, чтобы помочь нам перейти на централизованный сервер конфигурации в облаке.В настоящее время мы сохраняем и конфигурацию, и пароли в файле, доступ к которому имеют ограниченные пользователи в Production.У меня есть несколько вопросов о том, как реализовать его на практике с различными поддерживаемыми им бэкэндами:

  1. FileSystem : если мы используем файловую систему в качестве носителя для нашегоКонфиг на облаке, нам понадобится постоянный том для него.В этом случае PV будет отличаться для разных envs.Когда нам нужно обновить PV с помощью новой конфигурации в Prod, как это можно сделать?(Я могу думать только о том, чтобы контейнер смонтировал PV и вошел в контейнер через bash и добавить / обновить конфигурацию).Есть ли другой подход?

  2. Git : Если у нас есть git в качестве носителя данных и, скажем, у нас разные ветки для разных сред, разработчик сможетпросмотреть ветку Prod, а также пароли в ветке Prod.Гугл предположил, что нет способа ограничить просмотр определенных веток в Git.Так как Git полезен здесь?Кроме того, для подключения к Git требуется пароль / SSH-ключ, который необходимо будет сохранить в PV (тогда проблемы с # 1 снова применимы)

  3. JDBC : ЕслиУ нас есть база данных в качестве носителя данных, пароль для подключения к базе данных должен быть указан в файле конфигурации SCCS, что опять-таки небезопасно.Мы могли бы загрузить его из файла в файловой системе, но это означало бы, что нам нужен PV для хранения пароля (тогда проблемы с # 1 снова применимы).Кроме того, как добавляются / обновляются конфиги для Production?(Если используется СУБД, нам нужно подключить клиент и запустить вставки SQL?)

  4. Хранилище : Если будет использоваться хранилище, ему тоже потребуетсяключ / пароль для хранения в PV (и снова вопросы № 1)

В целом, я не уверен, как SCCS можно использовать в реальной производственной среде.Если кто-то внедрил SCCS for Production, в которой в его конфигурации есть пароли, не могли бы вы поделиться некоторыми идеями?

Спасибо,

Midhun

1 Ответ

0 голосов
/ 12 июля 2019

Пожалуйста, посмотрите на эту часть документации: Шифрование и дешифрование .Таким образом, только сервер конфигурации может шифровать / дешифровать значения, которые хранятся во внешних файлах конфигурации.Используйте TLS и базовую аутентификацию, чтобы только приложения могли получить доступ к конечной точке дешифрования, и она была надежно отправлена ​​между клиентом и сервером.

Если вы работаете в Kubernetes (потому что вы упомянули PV), вы можете использовать секреты и использоватьзначения внутри секрета, как среда, изменяется в вашем контейнере.Создайте отдельное пространство имен для централизованного сервера конфигурации и ограничьте доступ к команде, которая управляет этим, используя RBAC .Это также относится к клиентам, которым необходимо иметь учетные данные для доступа к серверу, если вы будете следовать базовой настройке аутентификации.Просто добавьте заполнители в файл bootstrap.properties для URL, имени пользователя и пароля для сервера конфигурации, и все готово.

Еще одна вещь, которую следует учитывать, - это наличие нескольких репозиториев git, которые как на сервере конфигурации, так и на сервере.соответствующие команды могут получить доступ.Таким образом, команда A не может получить доступ к репозиторию конфигурации команды B.

Надеюсь, это поможет!:)

...