Как использовать secrets.yml для API_KEYS в Rails 4.1?

В одном из моих последних проектов я начал с .gitignoring среды [environment/production.rb/development.rb/test.rb] и т.д. Таким образом, весь проект передается в репо, за исключением файлов, содержащих секреты и API_Keys, таких как Stripe, Twitter API, FB Graph API или инициализаторы /secret _token.rb в другом месте.

Теперь я нахожусь в точке, где проект будет жить (взволнован!), и мне нужно ввести все среды_вариайи и секреты на производственный сервер, когда cap production deploy.

В случае инициализаторов /secret _token.rb ясно, что Rails 4.1 имеет новый механизм использования secrets.yml файла, чтобы вывести значение: secret_key_base в производственный сервер. Здесь я рекомендую использовать capistrano-secrets-yml драгоценный камень, который прост в использовании, работает прямо из коробки.

Остается способ переноса на рабочий сервер других секретов, таких как API_KEYS, APP_ID и т.д., не проверяя их в репо. Как это сделать, что является наиболее рекомендуемым/безопасным способом или наилучшей практикой?

ПРИМЕЧАНИЕ. Я буду редактировать вопрос по мере его продвижения/я получаю больше ясности.

EDIT1: Сервер - это VPS Ubuntu/Linux на DigitalOcean. [Ответ на Denise ниже].

EDIT2: Может ли env_variables/secrets переноситься на сервер через secrets.yml? Secret_token для сеансов - это не единственный секрет! [Отвечено на Edit3]

EDIT3: Да! Это можно отправить в API_keys через secrets.yml в соответствии с этим blog. Поделитесь своими выводами когда-нибудь.: -)

ОТВЕТЫ

Ответ 1

Первое правило: НЕ ПРОВЕРИТЬ secrets.yml в репо.

Хорошо, вот как выглядел бы secret.yml:

development:
  secret_key_base: 6a1ada9d8e377c8fad5e530d6e0a1daa3d17e43ee... 
  # Paste output of $ rake secret here for your dev machine.

test:
  secret_key_base: _your_secret_ as above

production:
  secret_key_base: <%= secure_token %>


  STRIPE_PUBLISHABLE_KEY: 'Put your stripe keys for production'
  STRIPE_SECRET_KEY: 'Put actual keys for production here'
  FB_APP_SECRET: 'same as above'
  FB_CALLBACK_URL: 'FB url here'
  FB_CALLBACK_UPDATE_URL: 'FB url here'
  GOOGLE_KEY: 'Put your keys for production'
  GOOGLE_SECRET: 'same as above'
  TWITTER_KEY: 'same as above'
  TWITTER_SECRET: 'same as above'
  TWITTER_USERNAME: 'same as above'
  LINKEDIN_KEY: 'same as above'
  LINKEDIN_SECRET: 'same as above'

Обратите внимание на secure_token там в блоке production:. На рабочем сервере я использую инициализатор для динамически генерировать secret_tokens на лету.

sidenote: будьте осторожны с пробелами и вкладками внутри .yml файла. Он должен быть правильно отформатирован и разнесен (например, с пробелом после символа ":" ).

Чтобы настроить его на производство, вы можете распечатать файл непосредственно из своего локального файла или использовать capistrano-secrets-yml gem.

Это не сработает. См. Обновленный метод в соответствии с ответом @OddityOverseer ниже.

Для доступа к переменным среды в приложении environments/production.rb используйте:

FB_APP_SECRET            = ENV['FB_APP_SECRET']
FB_CALLBACK_URL          = ENV['FB_CALLBACK_URL']
FB_CALLBACK_UPDATE_URL   = ENV['FB_CALLBACK_UPDATE_URL']
GOOGLE_KEY               = ENV['GOOGLE_KEY']
GOOGLE_SECRET            = ENV['GOOGLE_SECRET']
TWITTER_KEY              = ENV['TWITTER_KEY']
TWITTER_SECRET           = ENV['TWITTER_SECRET']
TWITTER_USERNAME         = ENV['TWITTER_USERNAME']
LINKEDIN_KEY             = ENV['LINKEDIN_KEY']
LINKEDIN_SECRET          = ENV['LINKEDIN_SECRET']

ОБНОВЛЕНО Август-2016:

Для доступа к переменным среды в приложении environments/production.rb используйте:

FB_APP_SECRET            = Rails.application.secrets.FB_APP_SECRET
FB_CALLBACK_URL          = Rails.application.secrets.FB_CALLBACK_URL
FB_CALLBACK_UPDATE_URL   = Rails.application.secrets.FB_CALLBACK_UPDATE_URL
GOOGLE_KEY               = Rails.application.secrets.GOOGLE_KEY
GOOGLE_SECRET            = Rails.application.secrets.GOOGLE_SECRET
TWITTER_KEY              = Rails.application.secrets.TWITTER_KEY
TWITTER_SECRET           = Rails.application.secrets.TWITTER_SECRET
TWITTER_USERNAME         = Rails.application.secrets.TWITTER_USERNAME
LINKEDIN_KEY             = Rails.application.secrets.LINKEDIN_KEY
LINKEDIN_SECRET          = Rails.application.secrets.LINKEDIN_SECRET

Что об этом.

Ответ 2

Rails.application.secrets.key_name

Ответ 3

Один из способов сделать это - хранить эти секретные ключи в переменных среды. Как установить переменную окружения, зависит от того, в какой операционной системе вы находитесь. Для Linux-машины обычно вы редактируете файл .bashrc или .bash_profile в своем домашнем каталоге и добавляете строку, которая выглядит так:

export API_KEYS=apikeygoeshere

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

Затем в production.rb вы можете ссылаться на эти переменные среды как:

ENV["API_KEYS"]

Другой вариант - использовать рубиновый камень, который по сути позаботится об этом для вас, например, figaro. То, как это работает, заключается в том, что вы создаете другой файл, который вы не проверяете, и figaro позаботится о том, чтобы настроить их как переменные среды, которые затем можно найти в сценариях development.rb/production.rb, используя ENV["API_KEYS"] выше. Поскольку вы не проверяете файл, в котором есть все переменные среды, вам нужно найти способ получить этот файл на каких-либо машинах, выполняющих код.

Ответ 4

Я знаю, что этот вопрос специфичен для Rails 4.1, но те, кто обновляется до Rails 5.1, теперь включают встроенное в секретное поколение. Что представляется гораздо лучшим способом обработки конфиденциальных данных в вашем приложении rails.

Смотрите: http://edgeguides.rubyonrails.org/5_1_release_notes.html#encrypted-secrets