blackbox
v1.20220610
Stocker en toute sécurité les secrets dans un repo VCS (c'est-à-dire Git, mercurial, subversion ou performance). Ces commandes vous permettent de crypter des fichiers spécifiques de GNU Privacy Guard (GPG) dans un référentiel afin qu'ils soient "cryptés au repos" dans votre référentiel. Cependant, les scripts permettent de les déchiffrer facilement lorsque vous devez les visualiser ou les éditer, et les déchiffrer pour une utilisation en production. Écrit à l'origine pour Puppet, Blackbox fonctionne désormais avec n'importe quel référentiel Git ou Mercurial.
AVERTISSEMENT: Le but de ce projet est d'être un simple emballage autour de gpg afin que vous et vos collègues n'ayez pas à se souvenir de tous ces drapeaux impénétrables et déroutants. Il n'est pas destiné à être un système de chiffrement sophistiqué qui résout tous les problèmes ou prend en charge un grand nombre de fichiers. Le cas d'utilisation idéal est de garder les secrets dans un service sécurisé tels que conjur, kms AWS, Vault Key Azure ou KMS GCP; Utilisez ensuite BlackBox pour stocker en toute sécurité les touches API nécessaires pour accéder à ce système. De cette façon, vous chiffrez un seul fichier minuscule. Les requêtes de fonctionnalité pour quelque chose de plus seront rejetées; Ne vous attendez pas ou même demandez des "fonctionnalités d'entreprise". Si cela vous déçoit, veuillez envisager un projet concurrentiel tel que https://www.agwa.name/projects/git-crypt
Une présentation de diapositive (à environ une version plus ancienne) est sur Slideshare.
Rejoignez notre liste de diffusion: https://groups.google.com/d/forum/blackbox-project
Supposons que vous ayez un référentiel VCS (c'est-à-dire un repos git ou mercurial) et que certains fichiers contiennent des secrets tels que des mots de passe ou des clés privées SSL. Souvent, les gens stockent de tels fichiers "et espèrent que personne ne les trouvera dans le dépôt". Ce n'est pas sûr.
Avec BlackBox, ces fichiers sont stockés cryptés à l'aide de GPG. L'accès au dépôt VCS sans avoir également les bonnes clés GPG ne vaut rien d'avoir les fichiers. Tant que vous protégez vos clés GPG, vous n'avez pas à vous soucier de stocker votre dépôt VCS sur un serveur non fiable. Heck, même si vous faites confiance à votre serveur, vous n'avez plus à faire confiance aux personnes qui effectuent des sauvegardes de ce serveur ou aux personnes qui gèrent les bandes de sauvegarde!
Plutôt qu'une phrase de passe GPG pour tous les fichiers, chaque personne avec accès a ses propres clés GPG dans le système. Tout fichier peut être déchiffré par toute personne avec sa clé GPG. De cette façon, si une personne quitte l'entreprise, vous n'avez pas à communiquer un nouveau mot de passe à tous avec accès. Désactivez simplement la clé unique qui ne devrait plus avoir accès. Le processus de procédure est aussi simple que d'exécuter 2 commandes (1 pour désactiver leur clé, 1 pour ré-incrypothèse de tous les fichiers.)
Les processus automatisés ont souvent besoin d'accéder à tous les fichiers décryptés. C'est facile aussi. Par exemple, Supposons que GIT soit utilisé pour les fichiers de marionnettes. Le maître a besoin d'accès à la version décryptée de tous les fichiers. Configurez simplement une touche GPG pour le maître de marionnettes (ou le compte de rôle qui pousse de nouveaux fichiers au maître de marionnettes) et demandez à cet utilisateur d'exécuter blackbox_postdeploy une fois les fichiers mis à jour.
Si vous n'avez pas de touche GPG, configurez-le en utilisant des instructions telles que: configurer la clé GPG.
Maintenant, vous êtes prêt à partir.
cd dans un référentiel Git, Mercurial, Subversion ou Perforce et exécutez blackbox_initialize .
Si un fichier doit être crypté, exécutez blackbox_register_new_file et vous avez terminé.
Ajoutez et supprimez les touches avec blackbox_addadmin et blackbox_removeadmin .
Pour afficher et / ou modifier un fichier, exécutez blackbox_edit ; Cela décryptera le fichier et s'ouvrira avec tout ce qui est spécifié par votre variable d'environnement de l'éditeur $.
Lorsque vous fermez l'éditeur, le fichier sera automatiquement chiffré et le fichier en texte clair temporaire sera déchiqueté.
Si vous devez laisser le fichier déchiffré pendant que vous mettez à jour, vous pouvez utiliser le blackbox_edit_start pour décrypter le fichier et blackbox_edit_end lorsque vous souhaitez "le remettre dans la boîte".
De toute évidence, nous ne voulons pas que des choses secrètes comme les clés privées et les mots de passe SSL soient divulgués.
Pas si évidemment, lorsque nous stockons des "secrets" dans un dépôt VCS comme Git ou Mercurial, tout à coup, nous sommes moins en mesure de partager notre code avec d'autres personnes. La communication entre les sous-équipes d'une organisation est blessée. Vous ne pouvez pas collaborer aussi. Soit vous vous retrouvez en e-mail à des fichiers individuels (YUCK!), En faisant un référentiel spécial avec juste les fichiers nécessaires par vos collaborateurs (YUCK !!), ou simplement décider que la collaboration ne vaut pas tout cet effort (YUCK !!!).
La possibilité d'être ouverte et transparente sur notre code, à l'exception de quelques fichiers spécifiques, est la clé du type de collaboration que DevOps et des praticiens informatiques modernes doivent faire.
make copy-install copiera les fichiers bin dans $ prefix / bin, par défaut est / usr / local (désinstaller avec make copy-uninstall ).make symlinks-install rendra les symbseaux des fichiers bin en $ prefix / bin, par défaut est / usr / local (désinstaller avec make copy-uninstall ) (utile lors du développement)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm ; Vous pouvez maintenant distribuer le RPM via des méthodes locales. (Nécessite un FPM.)make packages-deb ; Vous pouvez maintenant distribuer le DEB via des méthodes locales. (Nécessite un FPM.)antigen bundle StackExchange/blackbox à votre .zshrczgenom load StackExchange/blackbox à votre .zshrc où vous chargez vos autres plugins.nix-shell -p blackboxpkgin in scm-blackbox| Nom: | Description: |
|---|---|
blackbox_edit <file> | Décrypter, exécuter $ éditeur, réincrirner un fichier |
blackbox_edit_start <file> | Décrypter un fichier pour qu'il puisse être mis à jour |
blackbox_edit_end <file> | Crypter un fichier après que Blackbox_Edit_start a été utilisé |
blackbox_cat <file> | Décrypter et afficher le contenu d'un fichier |
blackbox_view <file> | Comme Blackbox_Cat mais les tuyaux à less ou $ |
blackbox_diff | Différentes fichiers décryptés par rapport à leur version cryptée d'origine |
blackbox_initialize | Activer Blackbox pour un repo git ou hg |
blackbox_register_new_file <file> | Crypter un fichier pour la première fois |
blackbox_deregister_file <file> | Supprimer un fichier de Blackbox |
blackbox_list_files | Liste les fichiers entretenus par Blackbox |
blackbox_list_admins | Liste des administrateurs actuellement autorisés pour Blackbox |
blackbox_decrypt_file <file> | Décrypter un fichier |
blackbox_decrypt_all_files | Décrypter tous les fichiers gérés (interactifs) |
blackbox_postdeploy | Décrypter tous les fichiers gérés (lot) |
blackbox_addadmin <gpg-key> | Ajouter quelqu'un à la liste des personnes qui peuvent crypter / décrypter les secrets |
blackbox_removeadmin <gpg-key> | Supprimer quelqu'un de la liste des personnes qui peuvent crypter / décrypter les secrets |
blackbox_shred_all_files | Supprimer en toute sécurité tous les fichiers déchiffrés |
blackbox_update_all_files | Decrypt puis réencrypter tous les fichiers. Utile après que les clés sont modifiées |
blackbox_whatsnew <file> | Montrez ce qui a changé dans le dernier commit pour un fichier donné |
BlackBox détermine automatiquement quels VC que vous utilisez et font la bonne chose. Il a une architecture plug-in pour faciliter l'extension pour travailler avec d'autres systèmes. Il a été testé pour travailler avec de nombreux systèmes d'exploitation.
git - le githg - Mercurialsvn - Subversion (merci, Ben Drasin!)p4 - Ferme.blackbox est intact Pour ajouter ou fixer la prise en charge d'un système VCS, recherchez le code à la fin de bin/_blackbox_common.sh
Pour ajouter ou fixer la prise en charge d'un nouveau système d'exploitation, recherchez les instructions de cas dans bin/_blackbox_common.sh et bin/_stack_lib.sh et peut-être tools/confidence_test.sh
Blackbox peut être utilisé avec Cygwin, Mingw ou WSL2.
BlackBox suppose que blackbox-admins.txt et blackbox-files.txt aura des terminaisons de ligne LF. Les utilisateurs de Windows doivent veiller à configurer GIT ou d'autres systèmes pour ne pas convertir ou "corriger" ces fichiers.
Si vous utilisez GIT, ajoutez les lignes suivantes à votre fichier .gitattributes :
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
La dernière version de blackbox_initialize créera un fichier .gitattributes dans le répertoire $BLACKBOXDATA (généralement .blackbox ) pour vous.
Le support Cygwin nécessite les packages suivants:
Fonctionnement normal:
Développement (si vous ajoutez du code et que vous souhaitez exécuter le test de confiance)
Mingw (est livré avec Git pour Windows) le support nécessite les éléments suivants:
Fonctionnement normal:
MINTTY au lieu de la console Windows. Vous exécuterez BlackBox à partir de l'invite Git Bash.download.bat une fois qu'il a terminé Run install.bat puis ajoutez le chemin d'accès à ces outils à votre chemin (Ex: PATH=%PATH%;c:GnuWin32bin )Développement:
make test )Si vous obtenez l'erreur suivante dans WSL2, vous pouvez essayer de configurer votre environnement avec les instructions suivantes (testé avec Ubuntu 22.04 sur WSL2):
~/.gnupg/gpg-agent.conf sur WSL et ajoutez la ligne suivante: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeGPG a de nombreuses façons de crypter un fichier. BlackBox utilise le mode qui vous permet de spécifier une liste des clés qui peuvent décrypter le message.
Si vous avez 5 personnes («administrateurs») qui devraient pouvoir accéder aux secrets, chacun crée une clé GPG et ajoute leur clé publique au trousseau. La commande GPG utilisée pour crypter le fichier répertorie les 5 noms de clé, et donc toute clé 1 peut décrypter le fichier.
Pour supprimer l'accès de quelqu'un, supprimez le nom de la clé de cet administrateur (IE Adresse e-mail) de la liste des administrateurs et réintégrant tous les fichiers. Ils peuvent toujours lire le fichier .gpg (en supposant qu'ils ont accès au référentiel) mais ils ne peuvent plus le déchiffrer.
Et s'ils gardaient une copie de l'ancien dépôt avant de supprimer l'accès? Oui, ils peuvent décrypter les anciennes versions du fichier. C'est pourquoi lorsqu'un administrateur quitte l'équipe, vous devez modifier tous vos mots de passe, certificats SSL, etc. Vous auriez dû le faire avant Blackbox, non?
Pourquoi n'utilisez-vous pas des clés symétriques? En d'autres termes, pourquoi jouer avec tous ces trucs de clés GPG et à la place, à la place, ne cryptons-nous pas tous les fichiers avec une seule phrase de passe. Oui, GPG prend en charge cela, mais nous gérons ensuite un mot de passe partagé, qui est lourd de problèmes. Si quelqu'un "quitte l'équipe", nous devions communiquer à tout le monde un nouveau mot de passe. Maintenant, nous devons simplement supprimer leur clé. Cela évolue mieux.
Comment les processus automatisés se décryptent-ils sans demander de mot de passe? GPG nécessite une phrase secrète sur une clé privée. Cependant, il permet la création de sous-clés qui n'ont pas de phrase secrète. Pour les processus automatisés, créez une sous-clé uniquement stockée sur la machine qui doit décrypter les fichiers. Par exemple, chez Stack Exchange, lorsque notre système d'intégration continue (CI) pousse un changement de code à nos maîtres de marionnettes, ils exécutent blackbox_postdeploy pour décrypter tous les fichiers. L'utilisateur qui exécute ce code a une sous-clé qui ne nécessite pas de phrase de passe. Puisque nous avons de nombreux maîtres, chacun a sa propre clé. Et, oui, cela signifie que nos maîtres de marionnettes doivent être très sécurisés. Cependant, ils étaient déjà en sécurité parce que, comme, mec ... si vous pouvez pénétrer dans le maître de marionnettes de quelqu'un, vous possédez leur réseau.
Si vous utilisez Puppet, pourquoi n'avez-vous pas simplement utilisé Hiera-Eyaml? Il y a 4 raisons:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a ou hg commit Attendez ... cela peut être encore plus facile que ça! Exécutez blackbox_edit FILENAME , et il décryptera le fichier dans un fichier temporaire et appellera $EDITOR dessus, à nouveau après la fermeture de l'éditeur.
ANSIBLE VAULT fournit des fonctionnalités pour chiffrer les fichiers entiers et les chaînes stockées dans les fichiers; Cependant, le maintien du (s) mot de passe requis pour le déchiffrement n'est pas géré par ce module.
Au lieu de cela, il faut spécifier un fichier de mot de passe lors de l'exécution du playbook.
Exemple anible pour le fichier de mot de passe: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
Alternativement, on peut le spécifier dans la variable d'environnement ANSIBLE_VAULT_PASSWORD_FILE .
Des fichiers entiers, tels que les certificats SSL et les clés privés, sont traités comme des fichiers réguliers. Vous les décryptez chaque fois que vous poussez une nouvelle version au maître des marionnettes.
Exemple de marionnette pour un fichier chiffré: secret_file.key.gpg
file { '/etc/my_little_secret.key':
ensure => 'file',
owner => 'root',
group => 'puppet',
mode => '0760',
source => "puppet:///modules/${module_name}/secret_file.key",
}
Les petites chaînes, telles que les mots de passe et les clés API, sont stockées dans un fichier Hiera Yaml, que vous cryptez avec blackbox_register_new_file . Par exemple, nous utilisons un fichier appelé blackbox.yaml . Vous pouvez y accéder à l'aide de la fonction Hiera ().
Configuration: configurer hiera.yaml en ajoutant "Blackbox" à la hiérarchie de recherche:
:hierarchy:
- ...
- blackbox
- ...
Dans BlackBox.yaml Spécifiez:
---
module::test_password: "my secret password"
Dans votre code de marionnettes, accédez au mot de passe comme vous le feriez pour toutes les données Hiera:
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
La variable $the_password contiendra "mon mot de passe secret" et peut être utilisé partout où les chaînes sont utilisées.
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
Plusieurs noms de fichiers peuvent être spécifiés sur la ligne de commande:
Exemple 1: enregistrez 2 fichiers:
blackbox_register_new_file file1.txt file2.txt
Exemple 2: Enregistrez tous les fichiers dans $DIR :
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
Cela se produit assez rarement, mais nous l'avons couvert:
blackbox_deregister_file path/to/file.name.key
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
.blackbox/blackbox-admins.txt est un fichier qui répertorie les utilisateurs en mesure de décrypter des fichiers. (Plus pédantie, c'est une liste des noms de clés GNUPG pour lesquels le fichier est chiffré.)
Pour rejoindre la liste des personnes pouvant modifier le fichier, il faut trois étapes; Vous créez une touche GPG et l'ajoutez à l'anneau de clé. Ensuite, quelqu'un qui a déjà accès vous ajoute au système. Enfin, vous devez tester votre accès.
Si vous n'avez pas déjà de clé GPG, voici comment en générer un:
gpg --gen-key
AVERTISSEMENT: Les nouvelles versions de GPG génèrent des clés qui ne sont pas comprises par les anciennes versions de GPG. Si vous générez une clé avec une nouvelle version de GPG, cela entraînera des problèmes pour les utilisateurs des anciennes versions de GPG. Par conséquent, il est recommandé de vous assurer que tous ceux qui utilisent BlackBox ont exactement la même version de GPG, soit générer des touches GPG en utilisant une version de GPG aussi ancienne que la version la plus ancienne de GPG utilisée par tous ceux qui utilisent BlackBox.
Choisissez les défauts par défaut pour les paramètres de chiffrement, 0 expiration. Choisissez une très bonne phrase secrète. Stockez une sauvegarde de la clé privée quelque part. Par exemple, gardez la copie de sauvegarde sur un lecteur USB qui est verrouillé en toute sécurité. Ou, au moins, mettez-le sur une machine sécurisée avec peu ou pas d'accès Internet, un cryptage à disque complet, etc. Votre employeur a probablement des règles sur la façon de stocker de telles choses.
FYI: Si la génération de la clé est lente, c'est généralement parce que le système ne génère pas suffisamment d'entropie. Conseil: ouvrez une autre fenêtre sur cette machine et exécutez cette commande: ls -R /
Maintenant que vous avez une clé GPG, ajoutez-vous en tant qu'administrateur:
blackbox_addadmin KEYNAME
... où "KeyName" est l'adresse e-mail répertoriée dans la clé GPG que vous avez créée précédemment. Par exemple:
blackbox_addadmin [email protected]
Lorsque la commande se termine avec succès, les instructions sur la façon de commettre ces modifications seront sorties. Exécutez la commande comme indiqué pour commettre les modifications. Cela ressemblera à ceci:
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
Puis poussez-le vers le repo:
git push
or
ht push
(or whatever is appropriate)
Remarque: Création d'un compte de rôle? Si vous ajoutez le pubring.gpg d'un compte de rôle, vous pouvez spécifier le répertoire où le fichier pubring.gpg peut être trouvé comme un 2ème paramètre: blackbox_addadmin [email protected] /path/to/the/dir
Demandez à quelqu'un qui a déjà accès à la réincrypt des fichiers de données. Cela vous donne accès. Ils décryptent et réencroignent simplement les données sans apporter de modifications.
Pré-vérification: Vérifiez que les nouvelles clés ont l'air bien.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
Par exemple, examinez le nom de clé (adresse e-mail) pour s'assurer qu'il est conforme aux normes d'entreprise.
Importez le trousseau dans votre porte-clés personnel et votre réincrypt:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
Poussez les fichiers ré-cryptés:
git commit -a
git push
or
hg commit
hg push
Assurez-vous que vous pouvez décrypter un fichier. (Suggestion: gardez un fichier factice en VC juste pour que les nouvelles personnes puissent s'entraîner.)
Exécutez simplement blackbox_removeadmin avec leur nom de clé puis réencrypt:
Exemple:
blackbox_removeadmin [email protected]
blackbox_update_all_files
Une fois la commande terminer, vous recevrez un rappel pour vérifier le changement et le pousser.
Notez que leurs clés seront toujours dans le ring clé, mais ils iront inutilisés. Si vous souhaitez nettoyer le clés, utilisez les commandes GPG normales et vérifiez le fichier.
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
L'anneau de clé n'a que des clés publiques. Il n'y a pas de clés secrètes à supprimer.
N'oubliez pas que cette personne a eu accès à tous les secrets à la fois. Ils auraient pu faire une copie. Par conséquent, pour être complètement sécurisé, vous devez modifier tous les mots de passe, générer de nouvelles clés SSL, et ainsi de suite comme quand quiconque avait un accès privilégié laisse une organisation.
Valider la fiabilité des clés est une tâche qui ne peut pas être accomplie par Blackbox; Il s'agit d'un sujet complètement externe qui doit être traité manuellement (de la même manière que la génération / la gestion de votre clé est, par exemple) ou par un mécanisme dédié (une entreprise CA avec des workflows correspondants par exemple). Mis à part les avantages "communs" d'un réseau de confiance (voir ici ou ici par exemple), il empêche également plusieurs erreurs.
Historiquement Blackbox utilisait et appliquait un modèle "Trust Every Key", mais cela a changé! Désormais, la décision de savoir si et comment utiliser les modèles de confiance PGP / GPG est laissée à l'utilisateur par configuration (ou par les défauts de défaut PGP / GPG).
Lors de la mise à jour des gens de Blackbox pourraient rencontrer des problèmes fonctionnels s'ils n'ont pas encore traité de la confiance des clés qu'ils utilisent. C'est le bon moment pour le faire et construit votre réseau de confiance maintenant!
Si vous avez un flux de travail externe en place qui garantit l'intégrité des touches que Blackbox utilise, vous voudrez peut-être désactiver les modèles de confiance PGP / GPG et compter sur ce flux de travail.
Cela peut être réalisé en déclarant toujours le "modèle de confiance", soit en passant le paramètre de ligne de commande --trust-model=always à votre binaire PGP / GPG lorsque vous utilisez BlackBox (en définissant un alias ou en utilisant la variable d'environnement (par exemple GPG="gpg2 --trust-model=always" ) ou une combinaison des deux) ou en définissant trust-model always dans votre gpg.conf (notez que cela désactive le Web de la confiance partout, pas seulement pour Blackbox).
AVERTISSEMENT: il est fortement désattaché de ne pas utiliser de validation clé du tout! Cela ouvre diverses façons de contourner la confidentialité de vos secrets cryptés!
BlackBox stocke ses données de configuration dans le sous-répertoire .blackbox . Les références plus anciennes utilisent keyrings/live . Pour la compatibilité en arrière, l'un ou l'autre fonctionnera.
Toute la documentation fait référence à .blackbox .
Vous pouvez convertir un vieux repo en renommant simplement le répertoire:
mv keyrings/live .blackbox
rmdir keyrings
Il n'y a aucune raison technique de convertir d'anciens repos, sauf qu'il est moins déroutant pour les utilisateurs.
Cette modification a été apportée dans le commit 60E782A0, version v1.20180615.
Les détails:
$BLACKBOXDATA . Si cette variable d'environnement est définie, c'est le répertoire qui sera utilisé. S'il répertorie un répertoire qui n'existe pas, Blackbox imprimera une erreur et quittera.$BLACKBOXDATA n'est pas défini: (qui est le cas d'utilisation typique)keyrings/live et l'utilisera s'il existe..blackbox par défaut sera utilisé. Si .blackbox n'existe pas, Blackbox imprimera une erreur et une sortie.Aperçu:
Pour ajouter "Blackbox" à un dépôt git ou mercurial, vous devrez faire ce qui suit:
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
Vous voudrez inclure le répertoire "bin" de Blackbox dans votre chemin:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
Si vous utilisez l'antigène, l'ajout antigen bundle StackExchange/blackbox à votre .zshrc téléchargera ce référentiel et l'ajoutera à votre chemin $.
Suivez les instructions pour "Comment endoctriner un nouvel utilisateur dans le système?". Faites uniquement l'étape 1.
Une fois cela fait, est une bonne idée de tester le système en s'assurant qu'un fichier peut être ajouté au système (voir "Comment inscrire un nouveau fichier dans le système?"), Et un autre utilisateur peut décrypter le fichier.
Faites un nouveau fichier et enregistrez-le:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
Décriptez-le:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
Reentez-le:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
Vous ne devriez voir que foo.txt.gpg car foo.txt devrait être parti.
L'étape suivante consiste à commettre foo.txt.gpg et à vous assurer qu'un autre utilisateur peut consulter, afficher et modifier le contenu du fichier. Cela reste comme un exercice pour le lecteur. Si vous avez envie de prendre un risque, ne commettez pas foo.txt.gpg et supprimez-le à la place.
c'est-à-dire que c'est ainsi qu'un maître de marionnette peut avoir accès aux données non cryptées.
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
Un utilisateur automatisé (un "compte de rôle") est celui qui doit être capable de décrypter sans phrase secrète. En général, vous voudrez le faire pour l'utilisateur qui tire les fichiers du dépôt au maître. Cela peut être automatisé avec Jenkins CI ou un autre système CI.
Les clés GPG doivent avoir une phrase secrète. Cependant, les phrases de passe sont facultatives sur les sous-clés. Par conséquent, nous créerons une clé avec une phrase secrète, puis créerons une sous-clé sans phrase de passe. Étant donné que la sous-clé est très puissante, elle doit être créée sur une machine très sécurisée.
Il y a une autre prise. Le compte de rôle ne peut probablement pas vérifier les fichiers dans git / mercurial. Il n'a probablement que l'accès en lecture seule au dépôt. C'est une bonne politique de sécurité. Cela signifie que le compte de rôle ne peut pas être utilisé pour télécharger les bits publics de sous-clé dans le dépôt.
Par conséquent, nous créerons la clé / sous-clé sur une machine sécurisée comme vous-même. De là, nous pouvons engager les parties publiques dans le repo. À partir de ce compte également, nous exporterons les pièces dont le compte a besoin, les copierons où le compte de rôle peut y accéder et les importer comme compte de rôle.
Protip: Si on vous demande de générer une entropie, envisagez de l'exécuter sur la même machine dans une autre fenêtre: sudo dd if=/dev/sda of=/dev/null
Pour le reste de ce doc, vous devrez effectuer les substitutions suivantes:
Remarque: Cela devrait être plus automatisé / scénarisé. Les correctifs sont les bienvenus.
Sur SecureHost, créez les clés du maître des marionnettes:
$ mkdir /tmp/NEWMASTER
$ cd /tmp/NEWMASTER
$ gpg --homedir . --gen-key
Your selection?
(1) RSA and RSA (default)
What keysize do you want? (2048) DEFAULT
Key is valid for? (0) DEFAULT
# Real name: Puppet CI Deploy Account
# Email address: [email protected]
Remarque: Plutôt qu'une véritable adresse e-mail, utilisez le nom d'utilisateur @ fqdn de l'hôte sur lequel la clé sera utilisée. Si vous utilisez ce compte de rôle sur de nombreuses machines, chacun devrait avoir sa propre clé. En utilisant le FQDN de l'hôte, vous pourrez savoir quelle clé est laquelle. Dans ce doc, nous nous référerons au nom d'utilisateur @ fqdn comme $ keyname
Enregistrez la phrase secrète dans un endroit sûr!
Créez une clé sous-clé qui n'a pas de mot de passe:
$ gpg --homedir . --edit-key svc_deployacct
gpg> addkey
(enter passphrase)
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
Your selection? 6
What keysize do you want? (2048)
Key is valid for? (0)
Command> key 2
(the new subkey has a "*" next to it)
Command> passwd
(enter the main key's passphrase)
(enter an empty passphrase for the subkey... confirm you want to do this)
Command> save
Exportez maintenant en toute sécurité ce répertoire vers Newmaster:
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
Sur newmaster, recevez la nouvelle configuration GNUPG:
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
De retour sur SecureHost, ajoutez la nouvelle adresse e-mail à .blackbox / Blackbox-admins.txt:
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
Vérifiez que Secring.gpg est un fichier de longueur zéro. Si ce n'est pas le cas, vous avez en quelque sorte ajouté une clé privée au clés. Recommencer.
cd .blackbox
ls -l secring.gpg
Commettre les changements récents:
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
Régénérer tous les fichiers cryptés avec la nouvelle clé:
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
Sur Newmaster, importez les clés et décryptez les fichiers:
sudo -u svc_sadeploy bash # Become the role account.
gpg --import /etc/puppet/.blackbox/pubring.gpg
export PATH=$PATH:/path/to/blackbox/bin
blackbox_postdeploy
sudo -u puppet cat /etc/puppet/hieradata/blackbox.yaml # or any encrypted file.
Protip: si vous obtenez "GPG: le décryptage a échoué: pas de clé secrète", vous avez oublié de réencrypter Blackbox.yaml avec la nouvelle clé.
Sur SecureHost, supprimez en toute sécurité vos fichiers:
cd /tmp/NEWMASTER
# On machines with the "shred" command:
shred -u /tmp/keys.tar
find . -type f -print0 | xargs -0 shred -u
# All else:
rm -rf /tmp/NEWMASTER
Câchons également tous les autres fichiers temporaires que vous pourriez avoir fabriqués.
Si la clé de quelqu'un a déjà expiré, Blackbox cessera de chiffrer. Vous voyez cette erreur:
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
Vous pouvez également détecter les clés qui sont sur le point d'expirer en émettant cette commande et en examinant manuellement les dates "expirées:":
gpg --homedir=.blackbox --list-keys
Ou ... Liste des UID qui expireront dans un mois à partir d'aujourd'hui: (Avertissement: Cela répertorie également les clés sans date d'expiration)
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
Voici comment remplacer la clé:
AVERTISSEMENT: Ce processus effacera tous les fichiers non cryptés que vous étiez en train de modifier. Copiez-les ailleurs et restaurez les modifications une fois terminé.
blackbox_removeadmin [email protected]
# This next command overwrites any changed unencrypted files. See warning above.
blackbox_update_all_files
git commit -m "Re-encrypt all files"
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m 'Cleaned [email protected] from keyring' .blackbox/*
git push
git pull
blackbox_addadmin [email protected]
git commit -m'NEW ADMIN: [email protected] .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
git push
git pull
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
git commit -m "Re-encrypt all files"
git push
Tous les fichiers qui ont été temporairement copiés dans la première étape afin de ne pas être écrasés peuvent désormais être copiés et réincarrés avec la commande blackbox_edit_end .
(Merci à @chishaku d'avoir trouvé une solution à ce problème!)
Il est possible de dire à Git de décrypter les versions du fichier avant de les exécuter via git diff ou git log . Pour y parvenir: faites:
.gitattributes en haut du référentiel GIT: *.gpg diff=blackbox
.git/config : [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
Et maintenant, des commandes comme git log -p file.gpg affichent un bon journal des modifications dans le fichier crypté.
gpg: filename: skipped: No public key - cela signifie généralement qu'il y a un élément dans .blackbox/blackbox-admins.txt qui n'est pas le nom de la clé. Soit quelque chose de non valide a été inséré (comme un nom de fichier au lieu d'un nom d'utilisateur), soit un utilisateur a quitté l'organisation et leur clé a été supprimée du trousseau, mais leur nom n'a pas été supprimé du fichier Blackbox-admins.txt.
gpg: decryption failed: No secret key - signifie généralement que vous avez oublié de réincrypter le fichier avec la nouvelle clé.
Error: can't re-encrypt because a key has expired. - La clé d'un utilisateur a expiré et ne peut plus être utilisée pour crypter. Suivez la pointe Remplacer les touches expirées.
FYI: Votre référentiel peut utiliser keyrings/live au lieu de .blackbox . Voir "Où est stocké la configuration?"
Si les fichiers sont copiés d'un dépôt, ils peuvent toujours être décryptés et modifiés. De toute évidence, les modifications, les modifications des clés, et telles seront perdues si elles sont faites en dehors du dépôt. Notez également que les commandes sont les plus susceptibles de fonctionner uniquement si elles sont exécutées à partir du répertoire de base (c'est-à-dire le parent vers le répertoire .blackbox).
Les commandes suivantes ont été testées en dehors d'un dépôt:
blackbox_postdeployblackbox_edit_startblackbox_edit_end L'implémentation actuelle stockera la boîte noire dans /keyrings à la racine de l'ensemble du dépôt. Cela créera un problème entre les environnements qui ont des racines différentes (c'est-à-dire la vérification / sur le développement vs /releases/foo en production). Pour contourner cela, vous pouvez export BLACKBOX_REPOBASE=/path/to/repo et définir une base spécifique pour votre référentiel.
Ceci a été initialement écrit pour GIT et prend en charge un engagement biphasé, dans lequel commit est un engagement local et "push" envoie le changement en amont au serveur de contrôle de version lorsque quelque chose est enregistré ou dégénéré avec le système. L'implémentation actuelle commit immédiatement un fichier (sur le serveur de subversion en amont) lorsque vous exécutez une commande blackbox_* .
Dans certaines situations, les membres de l'équipe ou les rôles automatisés doivent installer GPG 2.x aux côtés du système GPG version 1.x pour rattraper la version GPG de l'équipe. Sur Ubuntu 16, vous pouvez apt-get install gnupg2 qui installe le binaire gpg2. Si vous souhaitez utiliser ce binaire GPG2, exécutez chaque commande BlackBox avec gpg = gpg2.
Par exemple:
GPG=gpg2 blackbox_postdeploy
Nous accueillons des questions, des rapports de bogues et des commentaires!
Le meilleur endroit pour commencer est de rejoindre la liste de diffusion BlackBox-Project et de s'y demander.
Les bugs sont suivis ici dans GitHub. N'hésitez pas à signaler vous-même des bugs.
Les soumissions de code sont avec plaisir! Le code est assez facile à lire.
Obtenez le code:
git clone [email protected]:StackExchange/blackbox.git
Testez vos modifications:
make confidence
Cela traverse un certain nombre de tests système. Il crée un repo, crypte les fichiers, décrypte les fichiers, etc. Vous pouvez exécuter ces tests pour vérifier que les modifications que vous avez apportées n'ont rien cassé. Vous pouvez également utiliser ces tests pour vérifier que le système fonctionne avec un nouveau système d'exploitation.
Veuillez soumettre des tests avec des modifications de code:
La meilleure façon de changer Blackbox est via le développement axé sur les tests. Ajoutez d'abord un test aux tools/confidence.sh . Ce test devrait échouer et démontrer la nécessité du changement que vous êtes sur le point de faire. Corrigez ensuite le bogue ou ajoutez la fonction que vous souhaitez. Lorsque vous avez terminé, make confidence à tous les tests. Le PR que vous soumettez doit inclure votre code ainsi que le nouveau test. De cette façon, les tests de confiance s'accumulent à mesure que le système se développe car nous savons que les changements futurs ne cassent pas les anciennes fonctionnalités.
Remarque: Les tests supposent actuellement "Git" et n'ont été testés que sur CentOS, Mac OS X et Cygwin. Les correctifs sont les bienvenus!
Voici d'autres packages open source qui font quelque chose de similaire à Blackbox. Si vous les aimez mieux que Blackbox, veuillez les utiliser.
Git-Crypt a la meilleure intégration GIT. Une fois configuré, il est presque transparent pour les utilisateurs. Cependant, cela ne fonctionne qu'avec Git.
Ce contenu est publié sous la licence MIT. Voir le fichier licence.txt.
