ruby on rails - programas - ¿Cómo abro el código fuente de mis aplicaciones de Rails sin revelar las claves secretas y las credenciales de la aplicación?

ruby on rails tutorial español

Question

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

Mi pregunta es: ¿Cómo puedo hacer públicos estos repositorios sin revelar 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. ¿Todos estos usuarios están cambiando estos valores en sus entornos de implementación de alguna manera?

¡Algunos usuarios incluso exponen su secreto y clave de AWS! Otros, en cambio, establecerán su secreto de AWS a algo como:

ENV[''aws-secret'']

aunque no estoy seguro en qué punto están estableciendo ese valor.

Entonces, ¿cuáles son las mejores prácticas para el suministro abierto de su aplicación Rails sin comprometer la seguridad de su aplicación?

Answer 1

En realidad tomé una pista de tu pregunta, usando ENV.

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

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

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

Estoy hospedando mi proyecto en Heroku, así que agregué estas 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, ¿qué pasa si no estás usando Heroku? Obviamente, no soy un experto en cada implementación de rieles individuales (jeesh, ni siquiera un profesional de Heroku), pero un ejemplo de esto sería hacer un db: migrar para realizar pruebas.

$ RAILS_ENV=test rake db:migrate

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

Answer 2

No almacenar 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 solo los archivos de configuración de la versión versionados, junto con un script capaz de:

• Leer los valores correctos desde el repositorio externo.
• y compile el archivo de configuración final completo (con los valores secretos en él)

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

Answer 3

Recientemente 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 en configuración en cada implementación.

Tienda de configuración: 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 es posible que desee eliminar del control de origen todo el historial del archivo que utilizó estos valores secretos. Aquí hay una guía para hacer esto en Git que utilicé: http://help.github.com/removing-sensitive-data/

Answer 4

Si está usando .env , ponga un archivo .env en la raíz de su aplicación. (documentos del capataz)

.env tendrá

AWS_SECRET=xxx
AWS_ACCESS=yyy

Luego, cuando necesite usar las teclas, inserte:

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

Aunque es importante que no .env este .env en tu control de versión. Entonces, si estás usando git, agrega el .env a tu .gitignore .

Ronda de bonos ! - Heroku

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

1. Agregue manualmente las claves a través del heroku config:add
2. Utilice la gema heroku-config para sincronizar sus variables de entorno locales, en ambos sentidos.

Answer 5

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

Después de una investigación adicional, creo que la solución que estaba buscando era excluir cualquier cosa que almacenara un valor secreto de la rama principal de mi repositorio de Git (tal como lo dijo @VonC). Pero en lugar de leer esos archivos en un repositorio por separado, simplemente creo una nueva rama de "producción" y la añado.

De esta manera están excluidos de Master y puedo enviar eso a Github o algún otro representante público, simplemente bien. Cuando esté listo para desplegar, puedo retirar la rama de Producción y fusionar Master en ella e implementar Producción.

Necesito poder hacer esto porque Heroku y otros anfitriones requieren un solo repositorio de git para ser empujados a sus servidores.

Más información aquí:

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