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

Question

Mi proyecto de rieles personales utiliza algunas API para las cuales almaceno las claves/secretos de 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

TLDR: Uso de variables de entorno!

creo @ Bryce de comment ofrece una respuesta, que sólo voy a enjuagar. Parece que un enfoque Heroku recommends es usar variables de entorno para almacenar información sensible (cadenas de claves 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 local de la caja, que sólo se refieren a las variables de entorno cada vez que necesita los datos sensibles. 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 database.yml consigue Analizada solo en la inicialización de la aplicación o arranque de nuevo por lo que esto no debería afectar al 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 en el que no puede enviar ssh al servidor de producción, como hace Heroku, debe ver cómo configurar de forma remota variables de entorno. Para Heroku esto se hace con heroku config:add. Por lo tanto, por el mismo artículo, si tuviera S3 integrado en su aplicación y que tenía los datos sensibles que vienen de las variables de entorno:

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

Sólo tiene Heroku crear 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 2

Son probablemente el mejor poner en inicializadores (config/inicializadores/api.yaml) aunque creo que lo que tienes cocinado está bien. Agregue las claves reales a su archivo .gitignore y ejecute git rm config/environments/production.yml para eliminar esos datos confidenciales de su repositorio. Advertencia justa, eliminará ese archivo también, así que hazlo primero.

A continuación, basta con crear un archivo de configuración/ambientes/production.yml.example junto a su archivo actual con los detalles pertinentes, pero con los datos sensibles dejado fuera. Cuando lo saque a producción, solo copie el archivo sin el .example y sustituya los datos apropiados.

Answer 3

¿Qué tal esto ...

Crear un nuevo proyecto y comprobar en GitHub con los valores de marcador de posición en el production.yml y archivos development.yml.

actualización .gitignore incluir production.yml y development.yml.

Reemplace los valores de marcador de posición con sus secretos.

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

Y cualquiera puede clonar tu repositorio sin ningún paso adicional para crear archivos que faltan (que sólo va a sustituir los valores de marcador de posición como lo hizo).

¿Cumple con eso?

Answer 4

Usar variables de entorno.

En Rubí, son accesibles de este modo:

ENV['S3_SECRET'] 

dos razones:

1. Los valores no lo hará en control de código fuente.
2. "datos confidenciales" también conocido como contraseñas tienden a cambiar de una manera por el medio ambiente. p.ej. deberías usar diferentes credenciales S3 para desarrollo vs producción.

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

¿Cómo ellos utilizan a nivel local?
foreman y dotenv son ambos fáciles. O edite su shell.

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

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

¿No dificulta esto la tarea de 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.

Answer 5

Rails 4.1 tiene ahora una convención para él. 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 utilizar 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']%> 

de lo que puede acceder a este material bajo

Rails.application.secrets.s3_secret 

Su discutidos en detalle al principio del episodio this