Как делают меня открытый исходный код приложения моих направляющих, не выдавая секретные ключи и учетные данные приложения
У меня есть много приложений для направляющих, размещенных на GitHub. Они являются все в настоящее время частными, и я часто буду развертывать их из их репозитория GitHub. Я хотел бы смочь сделать некоторых из них открытым исходным кодом, точно так же, как те можно найти на http://opensourcerails.com.
Мой вопрос: Как я могу обнародовать эти репозитории, не отдавая супер секретные учетные данные?
Например, я могу посмотреть в/config/initializers/cookie_verification_secret.rb и видеть секрет cookie почти для каждых из них. Я не понимаю, как это приемлемо. Эти пользователи все изменяют эти значения в их развертывать среды так или иначе?
Некоторые пользователи даже выставляют свой секрет AWS и ключ! Другие вместо этого установят свой секрет AWS на что-то как:
ENV['aws-secret']
хотя я не уверен, в какой точке они устанавливают то значение.
Так, каковы лучшие практики для открытого определения источника Вашего приложения для направляющих, не ставя под угрозу безопасность Вашего приложения.
3 ответа
Недавно я прошел через это с одним из моих собственных приложений. Моим решением было хранить все секретное в YAML-конфигурационном файле с git-ignored, а затем обращаться к этому файлу с помощью простого класса в каталоге initializers. Конфигурационный файл хранится в папке 'shared' для развертывания Capistrano и копируется в config при каждом развертывании.
Хранилище конфигурации: http://github.com/tsigo/jugglf/blob/master/config/initializers/juggernaut.rb
Пример использования: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb
Вы также можете захотеть удалить из контроля исходного кода всю историю файла, в котором использовались эти секретные значения. Вот руководство для этого в Git, которое я использовал: http://help.github.com/removing-sensitive-data/
Никакого секретного значения не сохраняется. В любой момент истории репозитория Git.
Эти значения должны храниться в другом месте, оставляя только файлы конфигурации шаблонов с версией, а также сценарий, способный:
- читать правильные значения из внешнего репо
- и создавать окончательный файл конфигурации (с секретными значениями в нем)
Сохраняя набор данных отдельно (источники с одной стороны, секретные значения с другой), вы можете открыть исходный код репозитория с исходными кодами без каких-либо секретов.
[EDIT - Следующий метод имеет раздражение от необходимости переключиться на ветку Production для запуска "rails server", чтобы включить необходимые cookies. Таким образом, внесение правок во время работы сервера затруднено... и я всё ещё ищу хорошее решение]
После дальнейшего исследования я думаю, что решение, которое я искал, заключалось в исключении всего, что хранит секретное значение, из основной ветки моего Git-репо (как и сказал @VonC). Но вместо того, чтобы читать из этих файлов в отдельном репозитории, я просто создаю новую ветку "production" и добавляю их туда.
Таким образом, они исключаются из Master, и я могу выкладывать их на Github или в другие публичные репозитории. Когда я буду готов к развертыванию, я могу проверить ветку Production, объединить в нее Master и развернуть Production.
Мне нужно иметь такую возможность, потому что Heroku и другие хостеры требуют, чтобы на их серверы выкладывалась одна git-репо.
Больше информации здесь:
http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574