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

Ответ 1

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

Я думаю, что @Bryce comment предлагает ответ, который я просто очищу. Кажется, один подход рекомендует 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 разбирается только при инициализации или перезагрузке приложения, поэтому это не должно влиять на производительность. Таким образом, это решит его для вашей локальной разработки и для создания вашего репозитория. Если вы лишены конфиденциальных данных, вы можете использовать тот же репозиторий для публики, как и в частном порядке. Он также решает проблему, если вы находитесь на 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. Работает для любого приложения, так как все они могут получить переменные окружения.

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

Использовать переменные среды.

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

ENV['S3_SECRET']

Две причины:

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

Является ли это лучшей практикой?
Да: http://12factor.net/config

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

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

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

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

Ответ 5

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

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