rails deploy commands ruby-on-rails security capistrano

ruby on rails - deploy - ¿Cómo usar secrets.yml para API_KEYS en Rails 4.1?



deploy capistrano rails (4)

En uno de mis proyectos recientes comencé por .gitignoring los archivos que contienen secretos y variables de entorno. Por lo tanto, todo el proyecto se compromete con el repositorio, excepto los archivos que contienen secretos de terceros como Stripe, la API de Twitter o Facebook Graph o las teclas internas de api_keys, como el archivo ./config/initializers/secret_token.rb .

Ahora estoy en un punto en el que el proyecto está a punto de ejecutarse (¡estoy emocionado!) Y necesito transferir todas las variables de entorno al servidor de producción utilizando Capistrano, es decir cap production deploy.

[Edit 4: Yr, 2018] En el caso de initializers / secret_token.rb, está claro que Rails 4.1 tiene una nueva forma de manejar el archivo secrets.yml que extrae el valor: secret_key_base al servidor de producción. Aquí, recomiendo usar la gema capistrano-secrets-yml que funciona de inmediato y es muy fácil de usar.

Lo que queda es la forma de llevar otros secretos como API_KEYS, APP_IDs, etc. al servidor de producción sin registrar ninguno de ellos en el repositorio. ¿Cómo hacer esto, cuál es la forma más recomendada / más segura o las mejores prácticas?

NOTA: Estaré editando la pregunta a medida que progrese / Tengo más claridad.

EDIT1: El servidor es un VPS de Ubuntu / Linux en DigitalOcean [Respuesta a Denise, a continuación].

EDIT2: ¿Se pueden llevar las env_variables / secretos al servidor a través de secrets.yml? Secret_token para sesiones no es el único secreto después de todo! [Respondido en Edit3]

EDIT3: ¡Sí! Es posible enviar las API_keys a través de secrets.yml de acuerdo con este blog . Compartiré mis hallazgos en algún momento. :-)

Primera regla: NO CHECK-IN secrets.yml en el repositorio.

De acuerdo, así es como se secret.yml un secret.yml .

development: secret_key_base: 6a1ada9d8e377c8fad5e530d6e0a1daa3d17e43ee... # Paste output of $ rake secret here for your dev machine. test: secret_key_base: _your_secret_ as above production: secret_key_base: <%= secure_token %> STRIPE_PUBLISHABLE_KEY: ''Put your stripe keys for production'' STRIPE_SECRET_KEY: ''Put actual keys for production here'' FB_APP_SECRET: ''same as above'' FB_CALLBACK_URL: ''FB url here'' FB_CALLBACK_UPDATE_URL: ''FB url here'' GOOGLE_KEY: ''Put your keys for production'' GOOGLE_SECRET: ''same as above'' TWITTER_KEY: ''same as above'' TWITTER_SECRET: ''same as above'' TWITTER_USERNAME: ''same as above'' LINKEDIN_KEY: ''same as above'' LINKEDIN_SECRET: ''same as above''

Tenga en cuenta el secure_token allí en la production: bloque. En el servidor de producción estoy usando un inicializador para generar dinámicamente secret_tokens sobre la marcha.

sidenote: tenga cuidado con los espacios y las pestañas dentro del archivo .yml. Debe estar debidamente formateado y espaciado (como tener un espacio después del símbolo '':'').

Para configurarlo para la producción, puede crear el archivo directamente desde su local o usar la gema capistrano-secrets-yml .

Esto no funcionará. Vea un método actualizado según la respuesta de @ OddityOverseer a continuación.

Para acceder a las variables de entorno en sus environments/production.rb aplicación environments/production.rb use:

FB_APP_SECRET = ENV[''FB_APP_SECRET''] FB_CALLBACK_URL = ENV[''FB_CALLBACK_URL''] FB_CALLBACK_UPDATE_URL = ENV[''FB_CALLBACK_UPDATE_URL''] GOOGLE_KEY = ENV[''GOOGLE_KEY''] GOOGLE_SECRET = ENV[''GOOGLE_SECRET''] TWITTER_KEY = ENV[''TWITTER_KEY''] TWITTER_SECRET = ENV[''TWITTER_SECRET''] TWITTER_USERNAME = ENV[''TWITTER_USERNAME''] LINKEDIN_KEY = ENV[''LINKEDIN_KEY''] LINKEDIN_SECRET = ENV[''LINKEDIN_SECRET'']

ACTUALIZADO Agosto-2016:

Para acceder a las variables de entorno en sus environments/production.rb aplicación environments/production.rb use:

FB_APP_SECRET = Rails.application.secrets.FB_APP_SECRET FB_CALLBACK_URL = Rails.application.secrets.FB_CALLBACK_URL FB_CALLBACK_UPDATE_URL = Rails.application.secrets.FB_CALLBACK_UPDATE_URL GOOGLE_KEY = Rails.application.secrets.GOOGLE_KEY GOOGLE_SECRET = Rails.application.secrets.GOOGLE_SECRET TWITTER_KEY = Rails.application.secrets.TWITTER_KEY TWITTER_SECRET = Rails.application.secrets.TWITTER_SECRET TWITTER_USERNAME = Rails.application.secrets.TWITTER_USERNAME LINKEDIN_KEY = Rails.application.secrets.LINKEDIN_KEY LINKEDIN_SECRET = Rails.application.secrets.LINKEDIN_SECRET

Eso es todo.

Una forma de hacerlo es almacenar esas claves secretas en variables de entorno. La forma de configurar una variable de entorno es diferente según el sistema operativo en el que se encuentre. Para una máquina Linux, normalmente estás editando un archivo .bashrc o .bash_profile en tu directorio de inicio y agregando una línea que parece:

export API_KEYS=apikeygoeshere

Tendrás que editar el archivo para cualquier usuario que ejecute rieles.

Luego, en production.rb , puedes referirte a esas variables de entorno como:

ENV["API_KEYS"]

Otra opción es usar una gema de rubí que esencialmente se encarga de eso por ti, como figaro. La forma en que funciona es crear otro archivo en el que no se registra y figaro se encarga de configurarlos como variables de entorno, a las que luego puede hacer referencia en sus scripts de desarrollo.rb / production.rb utilizando el ENV["API_KEYS"] arriba. Debido a que no está revisando el archivo que tiene todas las variables de entorno, tendrá que encontrar alguna manera de llevar ese archivo a cualquier máquina que esté ejecutando el código.

Rails.application.secrets.key_name