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

У меня есть ряд приложений Rails, размещенных на GitHub. Все они в настоящее время закрыты, и я часто разворачиваю их из своего репозитория GitHub. Я бы хотел, чтобы некоторые из них были с открытым исходным кодом, так же как те, которые вы можете найти на http://opensourcerails.com.

Мой вопрос: как я могу сделать эти репозитории общедоступными, не выдавая сверхсекретные учетные данные?

Например, я могу посмотреть в /config/initializers/cookie _verification_secret.rb и посмотреть секретный файл cookie почти для каждого из них. Я не понимаю, как это приемлемо. Являются ли эти пользователи каким-то образом меняют эти значения в своих средах развертывания?

Некоторые пользователи даже раскрывают секрет и ключ AWS! Другие вместо этого установят свой секрет AWS в нечто вроде:

ENV['aws-secret']

хотя я не уверен, в какой момент они устанавливают это значение.

Итак, каковы наилучшие методы открытого поиска вашего приложения Rails без ущерба для безопасности вашего приложения.

Ответы

Ответ 1

Недавно я прошел через это с помощью одного из моих собственных приложений. Мое решение состояло в том, чтобы хранить что-либо секретное в файле конфигурации git -ignored YAML, а затем для доступа к этому файлу с использованием простого класса в каталоге инициализаторов. Конфигурационный файл хранится в папке "shared" для развертывания Capistrano и скопирован в конфигурацию при каждом развертывании.

Конфигурация: 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/

Ответ 2

Если вы используете мастера, поместите файл .env в корень вашего приложения. (docs docs)

.env будет

AWS_SECRET=xxx
AWS_ACCESS=yyy

Затем, когда вам нужно использовать клавиши, вставьте:

ENV['AWS_SECRET']
ENV['AWS_ACCESS']

Хотя важно, чтобы вы не использовали этот .env для своего контроля версий. Поэтому, если вы используете git, добавьте .env к вашему .gitignore.

Бонусный раунд! - Heroku

При развертывании в Heroku эти переменные среды также должны быть настроены в среде Heroku. Существует два варианта:

  • Вручную добавьте ключи с помощью команды heroku config:add
  • Используйте heroku-config gem для синхронизации ваших переменных локальной среды в обоих направлениях.

Ответ 3

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

  • для чтения правильных значений из внешнего репо
  • и завершите окончательный файл конфигурации (с секретными значениями в нем)

Сохраняя набор данных буксировки отдельно (источники с одной стороны, секретные значения на другом), вы можете затем открыть исходный источник репо без каких-либо секретов.

Ответ 4

На самом деле я понял из вашего вопроса, используя ENV.

У меня было три разных секретных значения, которые я не хотел делать доступными. Конечно, это секретный токен приложения, а также ключ и секретный ключ Twitter. В моем секретном инициализаторе токена:

KinTwit::Application.config.secret_token = ENV['SECRET_TOKEN']

Twitter.consumer_key                     = ENV['CONSUMER_KEY']
Twitter.consumer_secret                  = ENV['CONSUMER_SECRET']

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

[03:07:48] [[email protected] ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_KEY=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v7
  CONSUMER_KEY => ub3rs3cr3tk3y
[03:08:40] [[email protected] ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_SECRET=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v8
  CONSUMER_SECRET => ub3rs3cr3tk3y
[03:08:57] [[email protected] ~/dev/rwc/kintwit]$ heroku config:add SECRET_TOKEN=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v9
  SECRET_TOKEN => ub3rs3cr3tk3y

Теперь значения готовы к следующему нажатию. Но что, если вы не используете Heroku? Я, очевидно, не специалист по каждому развертыванию рельсов (jeesh, даже не Heroku pro), но пример этого будет делать db: migrate для тестирования.

$ RAILS_ENV=test rake db:migrate

Параметр KEY = value перед командой устанавливает переменную среды, поэтому при запуске этой команды echo ENV['RAILS_ENV'] будет печатать test. Таким образом, однако, это настроено в вашей среде, как вы это сделаете. Но переменные среды не находятся в вашем коде, поэтому трюк.

Ответ 5

[РЕДАКТИРОВАТЬ. В следующем методе есть раздражение, связанное с необходимостью перехода на производственную ветвь для запуска "сервера рельсов" для включения необходимых файлов cookie. Таким образом, редактирование, пока сервер затруднен... и я все еще ищу хорошее решение]

После дальнейшего изучения, я думаю, что решение, которое я искал, было исключить все, что хранило секретное значение из моей главной ветки Git репо (как @VonC). Но вместо того, чтобы читать эти файлы в отдельном репо, я просто создаю новую "производственную" ветвь и добавляю к ней.

Таким образом, они исключены из Мастера, и я могу подтолкнуть его к Github или к каким-либо другим публичным репо. Когда я буду готов к развертыванию, я могу проверить производственный филиал и объединить Master в него и развернуть Production.

Мне нужно это сделать, потому что Heroku и другие хосты требуют, чтобы один репозиторий Git был перенаправлен на их серверы.

Дополнительная информация здесь:

http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574