web-dev-qa-db-fra.com

Séparer secret_key_base dans Rails 5.2?

Je viens de passer de la version 5.1 à la version 5.2 et je suis assez confus quant à cette "meilleure" méthodologie pour stocker des secrets ...

Peut-être que je ne comprends pas, mais il semble que le développement et la production aient été «fusionnés» dans un SINGLE SECRET_KEY_BASE ainsi que master.key... est-ce correct?

Sinon, comment utiliser une clé principale séparée et SECRET_KEY_BASE en développement?

Que se passe-t-il si des développeurs m'aident et que je ne veux pas qu'ils connaissent ma clé principale (ou mes secrets) que j'utilise en production?

ruby-on-railsrubyruby-on-rails-5ruby-on-rails-5.2
8
Tallboy

Rails 5.2 a changé un peu cela. Pour les environnements de développement et de test, la base secret_key_base est générée automatiquement. Vous pouvez donc simplement le supprimer de secrets.yml ou de l’endroit où vous l’avez défini.

En ce qui concerne la production, il existe un fichier d’identifiants que vous pouvez générer et éditer en exécutant Rails credentials:edit. Cela créera également la clé principale dans config/master.key qui est uniquement utilisée pour chiffrer et déchiffrer ce fichier. Ajoutez ceci à gitignore pour qu'il ne soit partagé avec personne d'autre, ce qui devrait permettre de le partager avec d'autres développeurs.

Si tout cela vous semble un peu fastidieux, vous pouvez simplement l'ignorer et fournir le secret_key_base dans ENV. Rails vérifiera s'il est présent dans ENV["SECRET_KEY_BASE"] avant de se plaindre. 

5
tomca32

Il y a deux façons d'accéder à secret_key_base:

  1. Rails.application.credentials.secret_key_base
  2. Rails.application.secrets.secret_key_base

Rails 5 a pris le premier chemin par défaut.

vous pouvez modifier Rails.application.credentials.secret_key_base par Rails credentials:edit. pour tous les autres environnements, n'oubliez pas de définir la variable d'environnement Rails_MASTER_KEY avec le même contenu que config/master.key. le master.key est ignoré par défaut. De cette façon, la même clé secrète est utilisée pour tous les environnements. Si vous souhaitez utiliser différentes clés, vous devez contrôler vous-même les espaces de noms.

Si vous préférez la deuxième manière Rails.application.secrets.secret_key_base. vous devez créer config/secrets.yml:

development:
  secret_key_base: ...
test:
  secret_key_base: ...
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

n'oubliez pas de définir la variable d'environnement SECRET_KEY_BASE en production. Si le fichier config/secrets.yml est suffisamment secret, il est correct de changer <%= ENV["SECRET_KEY_BASE"] %> en texte brut.

rake secret peut générer une clé secrète aléatoire pour vous.

Je préfère la deuxième manière (ancienne), à ​​cause de simple.

4
Yi Feng Xie

J'ai utilisé ce joyau lorsque je ne voulais pas partager le master.production avec mes amis développeurs, ce qui, à mon avis, correspond exactement au même objectif que l'OP.

https://github.com/sinsoku/Rails-env-credentials

Vous pouvez avoir une clé principale pour chaque environnement, comme indiqué ci-dessous, afin de pouvoir choisir quelle clé vous souhaitez partager avec quels développeurs/déployeurs.

config/credentials-development.yml.enc
config/credentials-test.yml.enc
config/credentials.yml.enc
master-development.key
master-test.key
master.key

Chaque clé sera générée lorsque vous exécuterez pour la première fois quelque chose comme:

Rails env_credentials: éditer le développement

Si vous passez d'une configuration master.key à celle-ci, une erreur que vous pourriez rencontrer sera liée à config/database.yml dans laquelle Rails tente d'évaluer toutes les informations d'environnement, quel que soit l'environnement sur lequel vous vous trouvez .. commentez-les, Rails essaie toujours d’évaluer les parties erb.)

1
untidyhair