Comment puis-je sauvegarder mes clés secrètes et le mot de passe en toute sécurité dans mon système de contrôle de version ?

Question

Je garde les paramètres importants comme les noms d'hôte et les ports de développement et de production de serveurs dans mon système de contrôle de version. Mais je sais que c'est une mauvaise pratique de garder secrets (comme des clés privées et de la base de données des mots de passe) dans un dépôt VCS.

Mais des mots de passe, comme tout autre paramètre--semblent comme ils devraient être versionnés. Alors, quelle est la bonne façon de garder les mots de passe de la version contrôlée?

J'imagine qu'il consisterait à garder les secrets dans leur propre "secrets" paramètres du fichier et avoir que le fichier crypté et la version contrôlée. Mais quelles technologies? Et comment le faire correctement? Est-il une meilleure façon entièrement d'aller à ce sujet?

---

Je vous pose la question en général, mais dans mon cas précis, je voudrais stocker des clés secrètes et mots de passe pour un Django/Python site à l'aide de git et github.

Aussi, un idéal, une solution serait de faire quelque chose de magique quand je push/pull avec git--par exemple, si les mots de passe cryptés modifications du fichier de l'exécution d'un script qui demande un mot de passe et le déchiffre en place.

---

EDIT: Pour plus de clarté, je suis en demandant au sujet de l'endroit où stocker la production de secrets.

Answer 1

Vous avez tout à fait raison de vouloir crypter votre fichier de paramètres, tout en conservant le fichier dans le contrôle de version. Comme vous le mentionnez, la meilleure solution serait que le Git de manière transparente crypter certains fichiers sensibles lorsque vous appuyez sur eux, de sorte que localement (c'est à dire sur toute la machine de votre certificat de), vous pouvez utiliser le fichier de paramètres, mais Git ou Dropbox ou celui qui est le stockage de vos fichiers sous VC ne pas avoir la capacité de lire les informations en clair.

Tutoriel sur la Transparence de Chiffrement/Déchiffrement, au cours de Push/Pull

Ce gist https://gist.github.com/873637 montre un tutoriel sur la façon d'utiliser le Git du smudge/nettoyer le filtre de pilote avec openssl pour chiffrer de manière transparente poussé fichiers. Vous avez juste besoin de faire un peu de configuration initiale.

Résumé de la Façon dont il Fonctionne

Vous aurez essentiellement être la création d'un .gitencrypt le dossier contenant les 3 scripts bash,

clean_filter_openssl 
smudge_filter_openssl 
diff_filter_openssl 

qui sont utilisés par Git pour le décryptage, le cryptage, et le soutien Git diff. Un maître-mot de passe et le sel (fixe!) est définie à l'intérieur de ces scripts, et vous DEVEZ vous assurer que .gitencrypt n'est jamais vraiment poussé. Exemple clean_filter_openssl script:

#!/bin/bash

SALT_FIXED=<your-salt> # 24 or less hex characters
PASS_FIXED=<your-passphrase>

openssl enc -base64 -aes-256-ecb -S $SALT_FIXED -k $PASS_FIXED

Similaire pour smudge_filter_open_ssl et diff_filter_oepnssl. Voir Les Gist.

Votre repo avec des informations sensibles doivent avoir un .gitattribute fichier (non chiffré et inclus dans le repo) qui fait référence à la .gitencrypt répertoire (qui contient tout ce qui Git besoins pour crypter/décrypter le projet de manière transparente) et qui est présent sur votre machine locale.

.gitattribute le contenu:

* filter=openssl diff=openssl
[merge]
    renormalize = true

Enfin, vous devrez également ajouter le contenu suivant votre .git/config le fichier

[filter "openssl"]
    smudge = ~/.gitencrypt/smudge_filter_openssl
    clean = ~/.gitencrypt/clean_filter_openssl
[diff "openssl"]
    textconv = ~/.gitencrypt/diff_filter_openssl

Maintenant, lorsque vous appuyez sur le référentiel contenant vos informations sensibles à un dépôt distant, les fichiers seront chiffrés de manière transparente. Lorsque vous tirez sur une machine locale qui a la .gitencrypt répertoire contenant votre mot de passe), les fichiers de manière transparente décrypté.

Notes

Je tiens à noter que ce tutoriel n'est pas de décrire une façon, à seulement crypter votre fichier de paramètres. De cette manière transparente chiffrer l'intégralité d'un référentiel qui est poussé à la distance de CR d'accueil et de décrypter l'ensemble du référentiel de sorte qu'il est entièrement décrypté localement. Pour obtenir le comportement que vous voulez, vous pouvez placer des fichiers sensibles pour un ou plusieurs projets dans un sensitive_settings_repo. Vous pourriez étudier comment cette technique de chiffrement transparent fonctionne avec des submodules http://git-scm.com/book/en/Git-Tools-Submodules si vous avez vraiment besoin de le fichiers sensibles dans le même référentiel.

L'utilisation d'un fixe phrase pourrait théoriquement conduire à la force brute des vulnérabilités si les pirates ont eu accès à de nombreux chiffré repos/fichiers. OMI, la probabilité pour que ce soit très faible. Comme une note au bas de ce tutoriel mentionne pas l'utilisation d'un mot de passe multiterme entraînera des versions locales de pensions de titres sur des machines différentes, toujours montrant que des modifications ont eu lieu avec "git status".

Answer 2

Heroku pousse l'utilisation de variables d'environnement pour les paramètres et les clés secrètes:

L'approche traditionnelle pour le traitement de telles config vars est de les mettre sous la source dans un fichier de propriétés d'une certaine sorte. C'est source d'erreurs, et est d'autant plus compliqué pour l'open source applications qui ont souvent pour maintenir séparés (et privé) branches avec application des configurations spécifiques.

Une meilleure solution consiste à utiliser des variables d'environnement, et de garder les clés de la code. Sur un traditionnel de l'hôte ou de travailler localement, vous pouvez définir des variables d'environnement dans votre bashrc. Sur Heroku, vous utilisez config vars.

Avec Foreman et .env fichiers Heroku fournir une enviable de la chaîne d'exporter, d'importer et de synchroniser les variables d'environnement.

---

Personnellement, je crois que c'est mauvais pour enregistrer les clés secrètes aux côtés de code. C'est fondamentalement incompatible avec le contrôle de source, parce que les touches sont pour les services d'extrinsèque à la la code. Une aubaine serait qu'un développeur peut clone de la TÊTE et de l'exécution de l'application sans aucune configuration. Cependant, supposons qu'un développeur récupère un historique de révision du code. Leur copie comprendra l'année dernière base de données de mot de passe, de sorte que l'application ne pourra pas aujourd'hui de base de données.

Avec le Heroku méthode ci-dessus, un développeur peut la caisse de l'année dernière application, configurez-le avec les touches, et de l'exécuter avec succès contre, aujourd'hui, la base de données.

Answer 3

À mon avis, la plus propre consiste à utiliser des variables d’environnement. Vous n’aurez pas à traiter les fichiers .dist par exemple, et l’état de projet sur l’environnement de production serait le même que votre machine locale.

Je recommande la lecture La douze-facteur Appconfig chapitre, les autres aussi si vous êtes intéressé.

Answer 4

Une option serait de mettre le projet lié aux informations d’identification dans un conteneur chiffré (TrueCrypt ou Keepass) et poussez-le.

Mise à jour comme réponse de mon commentaire ci-dessous :

Question intéressante btw. Je viens de trouver ceci : github.com/shadowhand/git-encrypt qui semble très prometteur pour le chiffrement automatique

Answer 5

Je suggère à l’aide de configuration files pour cela et pas de version eux.

Vous pouvez toutefois des exemples de version des fichiers.

Je ne vois aucun problème de partager des paramètres de développement. Par définition, il ne doit contenir aucune donnée précieuse.