web-dev-qa-db-fra.com

Comment utiliser secrets.yml pour API_KEYS dans Rails 4.1?

Dans l'un de mes projets récents, j'ai commencé par .gitignoring les fichiers contenant des secrets et des variables d'environnement. Ainsi, l'ensemble du projet est engagé dans le référentiel à l'exception des fichiers qui contiennent des secrets tiers tels que celui de Stripe, Twitter API ou Facebook Graph ou api_keys interne, ala le ./config/initializers/secret_token.rb fichier.

Maintenant, je suis à un point où le projet est sur le point d'être mis en ligne (excité!) Et j'ai besoin de porter toutes les variables d'environnement sur le serveur de production en utilisant Capistrano, c'est-à-dire cap production deploy.

[Edit 4: Yr, 2018] Dans le cas des initialiseurs/secret_token.rb, il est clair que Rails 4.1 a une nouvelle façon de gérer fichier secrets.yml qui tire dans la valeur: secret_key_base du serveur de production. Ici, je recommande d'utiliser la gemme capistrano-secrets-yml qui fonctionne dès la sortie de la boîte et est très simple à utiliser.

Ce qui reste est le moyen de transporter d'autres secrets comme API_KEYS, APP_IDs etc. sur le serveur de production sans archiver aucun de ceux-ci dans le référentiel. Comment faire, quelle est la méthode la plus recommandée/la plus sûre ou les meilleures pratiques?

REMARQUE: je vais modifier la question à mesure qu'elle progresse/j'obtiens plus de clarté.

EDIT1: Le serveur est un VPS Ubuntu/Linux sur DigitalOcean [Réponse à Denise, ci-dessous].

EDIT2: Les env_variables/secrets peuvent-ils être transférés sur le serveur via secrets.yml? Secret_token pour les sessions n'est pas le seul secret après tout! [Répondu sur Edit3]

EDIT3: Oui! Il est possible d'envoyer les API_keys via secrets.yml selon ceci blog . Partage mes conclusions dans un certain temps. :-)

ruby-on-railssecuritycapistrano
25
marvindanig

Première règle: NE PAS ENREGISTRER secrets.yml dans le référentiel.

Très bien, voici comment un secret.yml voudrais regarder:

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'

Noter la secure_token là-haut dans le production: bloquer. Sur le serveur de production, j'utilise un initialiseur pour générer dynamiquement secret_tokens à la volée.

sidenote: faites attention aux espaces et aux tabulations à l'intérieur du fichier .yml. Il doit être correctement formaté et espacé (comme avoir un espace après le symbole ":").

Pour le configurer en production, vous pouvez ensuite scp le fichier directement à partir de votre section locale ou utiliser la gemme capistrano-secrets-yml .

Cela ne fonctionnera pas. Voir une méthode mise à jour selon la réponse de @ OddityOverseer ci-dessous.

Pour accéder aux variables d'environnement dans votre application environments/production.rb utilisation:

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']

MISE À JOUR août-2016:

Pour accéder aux variables d'environnement dans votre application environments/production.rb utilisation:

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

C'est à peu près ça.

43
marvindanig

Rails.application.secrets.key_name

30
dkniffin

Une façon de le faire est de stocker ces clés secrètes dans des variables d'environnement. La façon de définir une variable d'environnement est différente selon le système d'exploitation sur lequel vous vous trouvez. Pour une machine Linux, vous modifiez généralement un fichier .bashrc ou .bash_profile dans votre répertoire personnel et ajoutez une ligne qui ressemble à:

export API_KEYS=apikeygoeshere

Vous devrez modifier le fichier pour tout utilisateur qui exécutera Rails.

Puis dans production.rb, vous pouvez faire référence à ces variables d'environnement comme:

ENV["API_KEYS"]

Une autre option consiste à utiliser un Ruby gem qui s'occupe essentiellement de cela pour vous, comme figaro. La façon dont cela fonctionne est que vous créez un autre fichier que vous ne consignez pas et figaro prend soin de les configurer en tant que variables d'environnement, auxquelles vous pouvez ensuite vous référer dans vos scripts development.rb/production.rb en utilisant le ENV["API_KEYS"] au dessus. Étant donné que vous n'archivez pas le fichier contenant toutes les variables d'environnement, vous devrez trouver un moyen d'obtenir ce fichier sur les machines exécutant le code.

8
Denise

Je sais que cette question est spécifique à Rails 4.1, mais ceux qui passent à Rails 5.1 incluent désormais une génération secrète intégrée. Ce qui semble une bien meilleure façon de gérer les données sensibles dans votre Rails app.

Voir: http://edgeguides.rubyonrails.org/5_1_release_notes.html#encrypted-secrets

4
Michael Irey