Где хранить конфиденциальные данные в приложении public rails?

В моем личном проекте rails используется несколько API, для которых я храню ключи / секреты API в config / environment / production.yml и development.yml как глобальные переменные. Теперь я хочу подтолкнуть этот проект к github для использования другими, но я не хочу, чтобы у них были эти биты конфиденциальных данных. Я также не хочу, чтобы этот файл находился в .gitignore, потому что это необходимо для запуска приложения. Я подумал о том, чтобы разместить их в БД, но я надеюсь найти лучшее решение.

TLDR : используйте переменные среды!

Я думаю, комментарий @ Брайса дает ответ, который я просто вырву. Кажется, что один подход Heroku рекомендует использовать переменные среды для хранения конфиденциальной информации (строки ключей API, пароли базы данных). Поэтому просмотрите свой код и посмотрите, в котором у вас есть конфиденциальные данные. Затем создайте переменные среды (например, в файле .bashrc), которые хранят значения данных сенсибилита. Например, для вашей базы данных:

export MYAPP_DEV_DB_DATABASE=myapp_dev export MYAPP_DEV_DB_USER=username export MYAPP_DEV_DB_PW=secret 

Теперь в вашем локальном поле вы просто ссылаетесь на переменные среды, когда вам нужны конфиденциальные данные. Например, в database.yml:

 development: adapter: mysql2 encoding: utf8 reconnect: false database: <%= ENV["MYAPP_DEV_DB_DATABASE"] %> pool: 5 username: <%= ENV["MYAPP_DEV_DB_USER"] %> password: <%= ENV["MYAPP_DEV_DB_PW"] %> socket: /var/run/mysqld/mysqld.sock 

Я думаю, что database.yml анализируется только при инициализации или перезагрузке приложения, поэтому это не должно влиять на производительность. Таким образом, это решит его для вашей локальной разработки и для создания вашего репозитория. Если вы лишены конфиденциальных данных, вы можете использовать тот же repository для публики, как и в частном порядке. Он также решает проблему, если вы находитесь на VPS. Просто ssh к нему и настройте переменные среды на вашем рабочем хосте, как и в вашем окне разработки.

Между тем, если ваша производственная установка включает в себя развертывание рук, где вы не можете ssh на производственный сервер, как это делает Heroku, вам нужно посмотреть, как дистанционно настроить переменные среды. Для Heroku это делается с heroku config:add . Итак, в той же статье, если у вас есть S3, интегрированный в ваше приложение, и у вас есть чувствительные данные, поступающие из переменных окружения:

 AWS::S3::Base.establish_connection!( :access_key_id => ENV['S3_KEY'], :secret_access_key => ENV['S3_SECRET'] ) 

Просто создайте для нее переменные среды Heroku:

 heroku config:add S3_KEY=8N022N81 S3_SECRET=9s83159d3+583493190 

Еще один профессионал в этом решении – это язык нейтральный, а не только Rails. Работает для любого приложения, так как все они могут получить переменные окружения.

Как насчет этого…

Создайте новый проект и проверьте его в GitHub с значениями-заполнителями в файлах production.yml и development.yml.

Обновите .gitignore, чтобы включить production.yml и development.yml.

Замените значения заполнителя вашими секретами.

Теперь вы можете проверить свой код на GitHub без ущерба для ваших секретов.

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

Соответствует ли это вашим целям?

Вероятно, они лучше всего вставляются в инициализаторы (config / initializers / api.yaml), хотя я думаю, что вы приготовили все в порядке. Добавьте фактические ключи в файл .gitignore и запустите git rm config/environments/production.yml чтобы удалить эти конфиденциальные данные из вашего репо. Справедливое предупреждение, оно также удалит этот файл, поэтому сначала поддержите его.

Затем просто создайте файл config / environment / production.yml.example рядом с вашим фактическим файлом с соответствующими сведениями, но с отсутствующими конфиденциальными данными. Когда вы вытаскиваете его на производство, просто скопируйте файл без .example и замените соответствующие данные.

Используйте переменные среды.

В Ruby они доступны так:

 ENV['S3_SECRET'] 

Две причины:

  1. Значения не будут попадать в исходное управление.
  2. «конфиденциальные данные», например, пароли, как правило, изменяются в зависимости от среды. например, вы должны использовать разные учетные данные S3 для разработки и производства.

Это лучшая практика?
Да: http://12factor.net/config

Как использовать их локально?
мастер и дотень – оба легко. Или отредактируйте свою оболочку .

Как использовать их в производстве?
Во многом это зависит. Но для Rails, dotenv – легкая победа.

Как насчет платформы как услуги?
Любой PaaS должен дать вам способ установить их. Например, Heroku: https://devcenter.heroku.com/articles/config-vars

Разве это не усложняет настройку нового разработчика для проекта?
Возможно, но это того стоит. Вы всегда можете проверить файл .env.sample в исходном элементе управления с некоторыми примерами данных. Добавьте примечание об этом в readme вашего проекта.

Rails 4.1 теперь имеет для нее соглашение. Вы храните этот материал в секретах .yml. Таким образом, вы не получаете некоторые глобальные вызовы ENV, разбросанные по вашему приложению.

Этот файл yaml похож на файл database.yml erb, поэтому вы все еще можете использовать вызовы ENV. В этом случае вы можете установить его под контроль версий, тогда он будет служить в качестве документации, которая должна использоваться в ENV vars. Но вы также можете вывести его из управления версиями и сохранить в нем настоящие секреты. В этом случае вы должны поместить некоторые secrets.yml.default или тому подобное в публичное репо для целей документации.

 development: s3_secret: 'foo' production: s3_secret: <%= ENV['S3_SECRET']%> 

Чем вы можете получить доступ к этим материалам в

 Rails.application.secrets.s3_secret 

Его подробно обсуждается в начале этого эпизода

Interesting Posts
Давайте будем гением компьютера.