¿Cómo abro las aplicaciones de Source my Rails sin regalar las credenciales y las claves secretas de la aplicación?

Question

Tengo una cantidad de aplicaciones de Rails alojadas en GitHub. Todos son actualmente privados, y a menudo los implementaré desde su repositorio de GitHub. Me gustaría poder hacer algunos de ellos de código abierto, como los que puedes encontrar en http://opensourcerails.com.

Mi pregunta es: ¿cómo puedo hacer que estos repositorios sean públicos sin regalar credenciales súper secretas?

Por ejemplo, puedo buscar en /config/initializers/cookie_verification_secret.rb y ver el secreto de cookies para casi todos ellos. No entiendo cómo esto es aceptable. ¿Están estos usuarios cambiando estos valores en sus entornos de implementación de alguna manera?

¡Algunos usuarios incluso exponen sus secretos y claves de AWS! Otros serán vez determinado su secreto AWS a algo como:

ENV['aws-secret'] 

aunque no estoy seguro de en qué momento se está configurando de ese valor.

Entonces, ¿cuáles son las mejores prácticas para la fuente abierta de su aplicación Rails sin comprometer la seguridad de su aplicación.

Answer 1

Hace poco pasé por esto con una de mis propias aplicaciones. Mi solución fue almacenar cualquier cosa secreta en un archivo de configuración YAML ignorado por git, y luego acceder a ese archivo usando una clase simple en el directorio de inicializadores. El archivo de configuración se almacena en la carpeta 'compartida' para la implementación de Capistrano y se copia a la configuración en cada implementación.

Config tienda: http://github.com/tsigo/jugglf/blob/master/config/initializers/juggernaut.rb

Ejemplo de uso: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb

También puede eliminar de control de origen de toda la historia del archivo que utiliza estos valores secretos. Aquí hay una guía para hacer esto en Git que utilicé: http://help.github.com/removing-sensitive-data/

Answer 2

No almacena ningún valor secreto en absoluto. En cualquier punto de la historia de un repositorio de Git.
Esos valores deben almacenarse en otro lugar, dejando a los archivos de configuración única plantilla versionadas, junto con un guión poder:

• para leer los valores de la derecha de la cesión temporal externa
• y construir el archivo de configuración final completo (con la valores secretos en él)

Al mantener separados los datos del conjunto de arrastre (fuentes en un lado, valores secretos en el otro), puede abrir el repositorio de fuentes sin ningún secreto.

Answer 3

[EDITAR - El siguiente método tiene la molestia de tener que cambiar a la rama Producción para ejecutar "servidor de rieles" para incluir las cookies necesarias. Por lo tanto, realizar ediciones mientras el servidor es difícil ... y todavía estoy buscando una buena solución]

Después de una investigación más profunda, creo que la solución que estaba buscando era excluir cualquier cosa que almacenara un valor secreto de mi Sucursal principal de Git repo (tal como dijo @VonC). Pero en lugar de leer esos archivos en un repositorio separado, simplemente creo una nueva rama de "producción" y los agrego a eso.

De esta manera están excluidos de la Maestra y puedo enviar eso a Github o a algún otro repositorio público.Cuando esté listo para implementar, puedo verificar la rama Producción y fusionar el Maestro en él e implementar Producción.

Necesito poder hacer esto porque Heroku y otros hosts requieren un solo repositorio git para ser enviado a sus servidores.

Más información aquí:

http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574

Answer 4

De hecho, me dio un indicio de su pregunta, el uso de ENV.

Tenía tres valores secretos diferentes que no quería que estuvieran disponibles. Son el token secreto de la aplicación, por supuesto, y la clave y el secreto del consumidor de Twitter. En mi secreto inicializador token:

KinTwit::Application.config.secret_token = ENV['SECRET_TOKEN'] 

Twitter.consumer_key      = ENV['CONSUMER_KEY'] 
Twitter.consumer_secret     = ENV['CONSUMER_SECRET'] 

que celebro mi proyecto en Heroku, por lo que añade estos como variables de configuración a Heroku.

[03:07:48] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_KEY=ub3rs3cr3tk3y 
Adding config vars and restarting app... done, v7 
    CONSUMER_KEY => ub3rs3cr3tk3y 
[03:08:40] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_SECRET=ub3rs3cr3tk3y 
Adding config vars and restarting app... done, v8 
    CONSUMER_SECRET => ub3rs3cr3tk3y 
[03:08:57] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add SECRET_TOKEN=ub3rs3cr3tk3y 
Adding config vars and restarting app... done, v9 
    SECRET_TOKEN => ub3rs3cr3tk3y 

Ahora, los valores están listos en mi próximo impulso. Pero, ¿y si no estás usando Heroku? Obviamente no soy un experto en el despliegue de cada riel (jeesh, ni siquiera un profesional de Heroku), pero un ejemplo de esto sería hacer un DB: migrar para probar.

$ RAILS_ENV=test rake db:migrate 

La clave = valor par antes de que el comando establece la variable de entorno, por lo que ejecutar este comando, echo ENV['RAILS_ENV'] imprimiría test. Entonces, sin embargo, esto está configurado en su entorno es cómo lo haría. Pero las variables de entorno no están en tu código, así que ese es el truco.

Answer 5

Si está utilizando capataz, ponga un archivo .env en la raíz de su aplicación. (foreman docs)

.env tendrá

AWS_SECRET=xxx 
AWS_ACCESS=yyy 

Luego, cuando es necesario utilizar las teclas, insertar:

ENV['AWS_SECRET'] 
ENV['AWS_ACCESS'] 

Aunque es importante que no se comprometen este .env a su control de versiones. Entonces, si está usando git, agregue .env a su .gitignore.

---

ronda de bonificación! - Heroku

Si se implementa en Heroku, estas variables de entorno también se deben configurar en el entorno Heroku. Hay dos opciones:

1. añadir manualmente las claves mediante el comando heroku config:add
2. Utilice la gema heroku-config para sincronizar las variables de entorno locales, en ambos sentidos.