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

Question

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

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

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

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

ENV['aws-secret']

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

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

Answer 1

Я недавно прошел через это с одним из моих собственных приложений. Мое решение состояло в том, чтобы сохранить что-нибудь секретное в файле конфигурации YAML, игнорируемом git, а затем получить доступ к этому файлу с помощью простого класса в каталоге initializer. Файл конфигурации хранится в папке «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/

Answer 2

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

.env будет иметь

AWS_SECRET=xxx
AWS_ACCESS=yyy

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

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

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

---

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

При развертывании в Heroku эти переменные среды также необходимо настроить в среде Heroku. Есть два варианта:

1. Добавление ключей вручную с помощью команды heroku config:add
2. Используйте гем heroku-config для синхронизации локальных переменных среды, оба способа.

Answer 3

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

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

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

Answer 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] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_KEY=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v7
  CONSUMER_KEY => ub3rs3cr3tk3y
[03:08:40] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_SECRET=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v8
  CONSUMER_SECRET => ub3rs3cr3tk3y
[03:08:57] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add SECRET_TOKEN=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v9
  SECRET_TOKEN => ub3rs3cr3tk3y

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

$ RAILS_ENV=test rake db:migrate

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

Answer 5

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

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

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

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

Больше информации здесь:

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