Как избежать хранения паролей в системе контроля версий?

Какую стратегию вы используете, чтобы избежать хранения паролей в системе контроля версий?

В настоящее время у меня есть пароли для разработки/тестирования/производства, сохраненные в трех разных файлах, и соответствующий файл используется во время развертывания. Все это связано с контролем версий, но я не слишком доволен этим, поскольку не всем разработчикам нужно знать эти пароли (особенно аутсорсинговым, которые имеют доступ только до тех пор, пока их проекты существуют, а это может быть всего месяц).

Хранение паролей в базе данных не лучший вариант:

  • Мне нужна большая часть данных во время инициализации контекста Spring (приложение Java), и я не хочу создавать строительные леса для подключения к одной базе данных, а затем подключаться к остальным базам данных и инициализировать остальную часть приложения.
  • некоторые пароли связаны только с развертыванием; пароль для доступа к различным серверам, хранилищам ключей и т. д.; это то, что приложение не может загрузить после запуска, так как оно вообще его не загружает

Я думаю о переносе конфигурации развертывания с компьютера разработчика на выделенный компьютер, который проверяет код из системы управления версиями и запускает сценарий сборки/развертывания, но я не совсем уверен, как лучше всего это сделать.

Я также должен сказать, что мне не нужна максимальная безопасность: я просто хочу избежать паролей на каждом диске разработчика и сделать это слишком простым.

Поэтому я прошу вашего опыта/лучших практик. Как ты это делаешь?


deployment passwords version-control password-protection
person Domchi    schedule 17.09.2009    source источник
comment
Эта тема Hacker News отлично подходит для этой темы.   -  person toraritte    schedule 26.06.2019

Ответы (6)


arrow_upward
10
arrow_downward

Свойства конфигурации, зависящие от среды. Я обычно добавляю, скажем, файл свойств, который не находится в системе управления версиями и не является частью процесса сборки. При настройке новой среды часть этой настройки заключается в том, чтобы создать этот файл свойств, который включает такие вещи, как адреса базы данных, учетные данные и имена, имена соответствующих удаленных хостов и так далее.

В Spring вы используете PropertyPlaceholderConfigurer, чтобы загрузить файл свойств. Он просто должен быть доступен для Spring, что обычно означает размещение его в соответствующем каталоге на сервере приложений.

В качестве альтернативы вы можете использовать оболочку для запуска сервера приложений, а параметры запуска JVM включают добавление эти файлы свойств в путь к классам, чтобы Spring мог их найти.

person cletus    schedule 17.09.2009

arrow_upward
7
arrow_downward

Я видел два подхода к этому:

  • Переместите пароли в другое дерево системы управления версиями, к которому у разработчиков нет доступа.
  • Не вводите никакие пароли в систему управления версиями, и специальный менеджер сборки должен вводить пароли каждый раз, когда выполняется развертывание. Это было в банке, где полный рабочий день работал парень над процессами сборки/слияния/релизов.
person russau    schedule 17.09.2009
comment
Хранение паролей в другой ветке кажется правильным решением. Распределенные SCM, такие как git, делают это очень легко. - person hgmnz; 17.09.2009

arrow_upward
3
arrow_downward

Это работает не во всех случаях, но именно здесь проявляется великолепие использования NT AUTHORITY\NETWORK SERVICE в качестве удостоверения ваших служб. Если вы используете это удостоверение, вам не нужно поддерживать для него пароль — вы можете просто использовать учетные данные AD компьютера в форме ИМЯ ДОМЕНА\ИМЯ МАШИНЫ$ для доступа к защищенной сети и базе данных.

Есть, конечно, некоторые ключевые моменты, на которые следует обратить внимание, не последним из которых является то, что никакие два приложения с общей границей безопасности не размещаются таким образом на одном сервере.

person Dave Markle    schedule 17.09.2009

arrow_upward
0
arrow_downward

Поместите пароли в переменные среды пользователя o/s.

Только этот пользователь или root может прочитать значение, как и файл, но с нулевой вероятностью его проверки в системе управления версиями.

person Neil McGuigan    schedule 03.11.2013

arrow_upward
0
arrow_downward

Я думаю, что хорошо иметь local_settings вне репозитория.

https://stackoverflow.com/a/21570849/1675586

person iman    schedule 05.02.2014

arrow_upward
0
arrow_downward

Вместо того, чтобы не хранить их, вы можете хранить их в зашифрованном виде. Таким образом, вам не нужно постоянно отправлять файлы учетных данных через мгновенные сообщения или электронную почту, когда новый разработчик начинает работу ... Вам просто нужно один раз сообщить им мастер-пароль для конкретного проекта, чтобы они могли зашифровать учетные данные.

person codewandler    schedule 21.03.2016
comment
Проблема с этим и некоторыми другими предложениями заключается в том, что ключ, как я полагаю, все еще будет храниться в коде приложения. Как вы предлагаете расшифровывать пароли? Мастер-ключ может работать, если его вводить вручную, но это только второй лучший вариант. Лучше никогда не хранить пароли в системе контроля версий, даже в зашифрованном виде. Но наличие главного ключа может быть вторым лучшим вариантом, если учетные данные сделаны таким образом, чтобы разрешать доступ только к тому, что нужно учетной записи (SELECT, если обновления или удаления не требуются, и только для необходимых таблиц, например) - person adprocas; 03.10.2017