Où stocker les données sensibles dans l’application rails publics?

Mon projet de rails personnels utilise quelques API pour lesquelles je stocke les clés / secrets de l’API dans config / environment / production.yml et development.yml en tant que variables globales. Je veux maintenant pousser ce projet sur github pour que les autres puissent l’utiliser, mais je ne veux pas qu’ils contiennent ces bits de données sensibles. Je ne veux pas non plus ce fichier dans .gitignore car il est nécessaire pour que l’application s’exécute. J’ai envisagé de les placer quelque part dans la firebase database, mais j’espère trouver une meilleure solution.

TLDR : Utilisez les variables d’environnement!

Je pense que le commentaire de @Bryce offre une réponse, que je vais juste débusquer. Il semble qu’une approche recommandée par Heroku consiste à utiliser des variables d’environnement pour stocker des informations sensibles (chaînes de clé API, mots de passe de firebase database). Alors examinez votre code et voyez dans lequel vous avez des données sensibles. Créez ensuite des variables d’environnement (dans votre fichier .bashrc par exemple) qui stockent les valeurs de données sensivite. Par exemple pour votre firebase database:

export MYAPP_DEV_DB_DATABASE=myapp_dev export MYAPP_DEV_DB_USER=username export MYAPP_DEV_DB_PW=secret 

Maintenant, dans votre boîte locale, vous vous référez simplement aux variables d’environnement chaque fois que vous avez besoin des données sensibles. Par exemple dans database.yml:

 development: adapter: mysql2 encoding: utf8 reconnect: false database: <%= ENV["MYAPP_DEV_DB_DATABASE"] %> pool: 5 username: <%= ENV["MYAPP_DEV_DB_USER"] %> password: <%= ENV["MYAPP_DEV_DB_PW"] %> socket: /var/run/mysqld/mysqld.sock 

Je pense que database.yml est analysé juste au moment de l’initialisation ou du redémarrage de l’application, cela ne devrait donc pas avoir d’impact sur les performances. Cela résoudrait le problème pour votre développement local et pour rendre votre référentiel public. Dépourvus de données sensibles, vous pouvez désormais utiliser le même référentiel que le public, comme vous le faites en privé. Cela résout également le problème si vous êtes sur un VPS. Juste ssh à elle et configurez les variables d’environnement sur votre hôte de production comme vous l’avez fait dans votre boîte de développement.

En attendant, si votre configuration de production implique un déploiement interactif où vous ne pouvez pas accéder à ssh au serveur de production, comme le fait Heroku, vous devez examiner comment configurer à distance les variables d’environnement. Pour Heroku, cela se fait avec heroku config:add . Donc, selon le même article, si S3 était intégré à votre application et que vous disposiez des données sensibles provenant des variables d’environnement:

 AWS::S3::Base.establish_connection!( :access_key_id => ENV['S3_KEY'], :secret_access_key => ENV['S3_SECRET'] ) 

Il suffit que Heroku crée des variables d’environnement pour cela:

 heroku config:add S3_KEY=8N022N81 S3_SECRET=9s83159d3+583493190 

Un autre avantage de cette solution est que la langue est neutre, pas seulement Rails. Fonctionne pour n’importe quelle application car ils peuvent tous acquérir les variables d’environnement.

Que dis-tu de ça…

Créez un nouveau projet et vérifiez-le dans GitHub avec les valeurs des espaces réservés dans les fichiers production.yml et development.yml.

Mettez à jour le fichier .gitignore pour inclure production.yml et development.yml.

Remplacez les valeurs de l’espace réservé par vos secrets.

Vous pouvez maintenant vérifier votre code dans GitHub sans compromettre vos secrets.

Et n’importe qui peut cloner votre repository sans étapes supplémentaires pour créer des fichiers manquants (ils remplaceront simplement les valeurs fictives comme vous l’avez fait).

Est-ce que cela répond à vos objectives?

Il vaut probablement mieux les placer dans des initialiseurs (config / initializers / api.yaml) bien que je pense que ce que vous avez préparé est correct. Ajoutez les clés réelles à votre fichier .gitignore et exécutez git rm config/environments/production.yml pour supprimer ces données sensibles de votre repository. Avertissement correct, il va supprimer ce fichier aussi alors sauvegardez-le d’abord.

Ensuite, créez simplement un fichier config / environment / production.yml.example à côté de votre fichier actuel avec les détails pertinents, mais en laissant de côté les données sensibles. Lorsque vous le sortez en production, copiez simplement le fichier sans le .exemple et remplacez les données appropriées.

Utilisez les variables d’environnement.

En Ruby, ils sont accessibles comme ceci:

 ENV['S3_SECRET'] 

Deux raisons:

  1. Les valeurs ne seront pas converties en contrôle de source.
  2. Les “données sensibles”, c’est-à-dire les mots de passe, ont tendance à changer de manière inhérente à chaque environnement. Par exemple, vous devez utiliser des identifiants S3 différents pour le développement et la production.

Est-ce une bonne pratique?
Oui: http://12factor.net/config

Comment les utiliser localement?
contremaître et dotenv sont tous deux faciles. Ou, modifiez votre shell .

Comment les utiliser en production?
En gros, ça dépend. Mais pour Rails, dotenv est une victoire facile.

Qu’en est-il de la plate-forme en tant que service?
Tout PaaS devrait vous donner un moyen de les définir. Heroku par exemple: https://devcenter.heroku.com/articles/config-vars

Cela ne complique-t-il pas la mise en place d’un nouveau développeur pour le projet?
Peut-être, mais ça vaut le coup. Vous pouvez toujours vérifier un fichier .env.sample dans le contrôle de code source avec des exemples de données. Ajoutez une note à ce sujet au fichier Readme de votre projet.

Rails 4.1 a maintenant une convention pour cela. Vous stockez ces éléments dans secrets.yml. Ainsi, vous ne vous retrouvez pas avec des appels ENV mondiaux dispersés dans votre application.

Ce fichier yaml ressemble à database.yml erb analysé, vous pouvez donc toujours utiliser les appels ENV. Dans ce cas, vous pouvez le mettre sous contrôle de version, il ne servira alors que de documentation dont ENV vars doit être utilisé. Mais vous pouvez également l’exclure du contrôle de version et y stocker les secrets réels. Dans ce cas, placez des secrets.yml.default ou autres dans le repository public à des fins de documentation.

 development: s3_secret: 'foo' production: s3_secret: <%= ENV['S3_SECRET']%> 

Que vous pouvez accéder à ces choses sous

 Rails.application.secrets.s3_secret 

Son discuté en détail au début de cet épisode