ruby-on-rails - secrets - rails master key

Dónde almacenar datos confidenciales en la aplicación de rieles públicos?

Question

Mi proyecto de rieles personales usa algunas API para las cuales almaceno las claves / secretos API en config / environments / production.yml y development.yml como variables globales. Ahora quiero enviar este proyecto a Github para que otros lo utilicen, pero no quiero que tengan esos bits de datos confidenciales. Tampoco quiero este archivo en .gitignore porque es necesario para ejecutar la aplicación. He considerado ponerlos en el DB en alguna parte, pero espero encontrar una mejor solución.

Answer 1

Probablemente sean los mejores en inicializadores (config / initializers / api.yaml) aunque creo que lo que tienes preparado está bien. Agregue las claves reales a su archivo .gitignore y ejecute git rm config/environments/production.yml para eliminar los datos confidenciales de su repositorio. Advertencia justa, eliminará ese archivo también, así que hazlo primero.

Luego, solo crea un archivo config / environments / production.yml.example junto a tu archivo real con los detalles pertinentes pero con los datos confidenciales omitidos. Cuando lo saque a producción, solo copie el archivo sin el .example y sustituya los datos apropiados.

Answer 2

Qué tal esto...

Cree un nuevo proyecto y compruébelo en GitHub con valores de marcador de posición en los archivos production.yml y development.yml.

Actualice .gitignore para incluir production.yml y development.yml.

Reemplaza los valores del marcador de posición con tus secretos.

Ahora puede verificar su código en GitHub sin comprometer sus secretos.

Y cualquiera puede clonar su repositorio sin pasos adicionales para crear archivos perdidos (simplemente reemplazarán los valores del marcador de posición como lo hizo).

¿Cumple eso tus objetivos?

Answer 3

Rails 4.1 ahora tiene una convención para eso. Guardas estas cosas en secret.yml. Así que no terminas con algunas llamadas ENV globales repartidas por tu aplicación.

Este archivo yaml es como database.yml erb analizado, por lo que todavía puede usar las llamadas ENV aquí. En ese caso puede ponerlo bajo control de versión, entonces serviría como una documentación que ENV vars tiene que ser utilizada. Pero también puede exlcuirlo del control de versión y almacenar los secretos reales allí. En ese caso, pondría algunos secretos.yml.default o similares en el repositorio público para fines de documentación.

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

Que puedes acceder a esto debajo de

Rails.application.secrets.s3_secret

Es discutido en detalle al comienzo de this Episodio

Answer 4

TLDR : ¡usa variables de entorno!

Creo que el comment de comment ofrece una respuesta, que voy a aclarar. Parece que uno de los enfoques que Heroku recomienda es usar variables de entorno para almacenar información delicada (cadenas clave de API, contraseñas de bases de datos). Así que revise su código y vea en qué datos confidenciales. A continuación, cree variables de entorno (en su archivo .bashrc, por ejemplo) que almacenan los valores de datos sensivite. Por ejemplo para su base de datos:

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

Ahora, en su cuadro local, simplemente consulte las variables de entorno siempre que necesite los datos confidenciales. Por ejemplo en 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

Creo que database.yml se analiza solo en la inicialización o reinicio de la aplicación, por lo que no debería afectar el rendimiento. Entonces esto lo resolvería para su desarrollo local y para hacer público su repositorio. Sin datos confidenciales, ahora puede usar el mismo repositorio para el público que lo hace en privado. También resuelve el problema si estás en un VPS. Solo sáquelo y configure las variables de entorno en su host de producción como lo hizo en su cuadro de desarrollo.

Mientras tanto, si su configuración de producción implica un despliegue de manos libres donde no puede enviar ssh al servidor de producción, como lo hace Heroku, debe ver cómo configurar de forma remota las variables de entorno. Para Heroku esto se hace con heroku config:add . Entonces, según el mismo artículo, si tenía S3 integrado en su aplicación y tenía los datos confidenciales provenientes de las variables de entorno:

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

Simplemente haz que Heroku cree variables de entorno para ello:

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

Otro profesional de esta solución es que es un lenguaje neutral, no solo Rails. Funciona para cualquier aplicación ya que todas pueden adquirir las variables de entorno.

Answer 5

Usa variables de entorno

En Ruby, son accesibles de esta forma:

ENV[''S3_SECRET'']

Dos razones:

1. Los valores no pasarán al control de fuente.
2. Las contraseñas de "datos confidenciales" también tienden a cambiar en función del medio ambiente de todos modos. por ejemplo, debería usar credenciales S3 diferentes para desarrollo vs producción.

¿Es esta una mejor práctica?
Sí: http://12factor.net/config

¿Cómo los uso localmente?
ddollar.github.io/foreman/#ENVIRONMENT y dotenv son ambos fáciles. O edita tu shell .

¿Cómo los uso en producción?
En gran parte, depende. Pero para Rails, dotenv es una victoria fácil.

¿Qué pasa con la plataforma como servicio?
Cualquier PaaS debería darte una forma de configurarlos. Heroku por ejemplo: https://devcenter.heroku.com/articles/config-vars

¿No es esto más complicado configurar un nuevo desarrollador para el proyecto?
Quizás, pero vale la pena. Siempre puede verificar un archivo .env.sample en el control de código fuente con algunos datos de ejemplo en él. Agregue una nota sobre el archivo léame de su proyecto.