blackbox
v1.20220610
Speichern Sie Geheimnisse in einem VCS -Repo sicher (dh Git, Quecksilber, Subversion oder Perforce). Diese Befehle erleichtern es Ihnen leicht, GNU Privacy Guard (GPG) bestimmte Dateien in einem Repo zu verschlüsseln, damit sie in Ihrem Repository "in Ruhe verschlüsselt" sind. Die Skripte machen es jedoch einfach, sie zu entschlüsseln, wenn Sie sie anzeigen oder bearbeiten müssen, und sie für die Verwendung in der Produktion entschlüsseln. Ursprünglich für Puppet geschrieben, arbeitet Blackbox jetzt mit jedem Git- oder Mercurial -Repository.
Warnung: Ziel dieses Projekts ist es, ein einfacher Wrapper um gpg zu sein, sodass Sie und Ihre Mitarbeiter nicht daran erinnern müssen, dass all diese unergründlichen und verwirrenden Flaggen. Es ist nicht beabsichtigt, ein ausgeklügeltes Verschlüsselungssystem zu sein, das alle Probleme löst oder eine große Anzahl von Dateien unterstützt. Der ideale Anwendungsfall besteht darin, Geheimnisse in einem sicheren Dienst wie Conjur, AWS KMS, Azure Key Vault oder GCP-KMS zu halten. Verwenden Sie dann Blackbox, um die API -Schlüssel sicher zu speichern, die für den Zugriff auf dieses System erforderlich sind. Auf diese Weise verschlüsseln Sie eine einzelne, winzige Datei. Feature-Requests für etwas mehr werden abgelehnt; Erwarten oder sogar "Unternehmensfunktionen" oder gar nicht erwarten. Wenn dies Sie enttäuscht, sollten Sie ein konkurrierendes Projekt wie https://www.agwa.name/projects/git-crypt in Betracht ziehen
Eine Folienpräsentation (über eine ältere Version) befindet sich in Slideshare.
Treten Sie unserer Mailingliste bei: https://groups.google.com/d/forum/blackbox-project
Angenommen, Sie haben ein VCS -Repository (dh ein Git- oder Mercurial -Repo) und bestimmte Dateien enthalten Geheimnisse wie Passwörter oder SSL -private Schlüssel. Oft speichern die Leute solche Dateien nur "und hoffen, dass niemand sie im Repo findet". Das ist nicht sicher.
Mit Blackbox werden diese Dateien mit GPG verschlüsselt. Der Zugriff auf das VCS -Repo, ohne auch die richtigen GPG -Tasten zu haben, macht es wertlos, die Dateien zu haben. Solange Sie Ihre GPG -Tasten sicher halten, müssen Sie sich keine Sorgen machen, dass Sie Ihr VCS -Repo auf einem nicht vertrauenswürdigen Server speichern. Selbst wenn Sie Ihrem Server vertrauen, müssen Sie den Personen, die Backups dieses Servers durchführen, oder den Personen, die die Sicherungsbänder bewältigen, nicht vertrauen!
Anstelle einer GPG -Passphrase für alle Dateien hat jede Person mit Zugriff ihre eigenen GPG -Tasten im System. Jede Datei kann von jedem mit ihrem GPG -Schlüssel entschlüsselt werden. Auf diese Weise müssen Sie, wenn eine Person das Unternehmen verlässt, kein neues Passwort mit Zugriff aufweisen. Deaktivieren Sie einfach den einen Schlüssel, der keinen Zugriff mehr haben sollte. Der Vorgang dafür ist so einfach wie 2-Befehle auszuführen (1, um ihren Schlüssel zu deaktivieren, 1, um alle Dateien neu zu verkt).
Automatisierte Prozesse erfordern häufig Zugriff auf alle entschlüsselten Dateien. Das ist auch einfach. Angenommen, Git wird für Marionettendateien verwendet. Der Master benötigt Zugriff auf die entschlüsselte Version aller Dateien. Richten Sie einfach einen GPG -Schlüssel für den Puppet Master ein (oder das Rollenkonto, das neue Dateien zum Puppet -Master weitergibt) und lassen Sie diesen Benutzer nach der Aktualisierung von Dateien blackbox_postdeploy ausführen.
Wenn Sie keine GPG -Taste haben, richten Sie ihn mit Anweisungen wie: Einrichten von GPG -Schlüssel ein.
Jetzt bist du bereit zu gehen.
cd in ein Git-, Quecksilber-, Subversion- oder Perforce -Repository und run blackbox_initialize ausführen.
Wenn eine Datei verschlüsselt werden soll, führen Sie blackbox_register_new_file aus und Sie sind fertig.
Fügen Sie Tasten mit blackbox_addadmin und blackbox_removeadmin hinzu und entfernen Sie.
Um eine Datei anzuzeigen und/oder zu bearbeiten, führen Sie blackbox_edit aus. Dadurch wird die Datei entschlüsselt und mit dem geöffnet, was von Ihrer $ editorischen Umgebungsvariablen angegeben wird.
Wenn Sie den Editor schließen, wird die Datei automatisch erneut verschlüsselt und die temporäre Klartextdatei wird zerkleinert.
Wenn Sie die Datei während der Aktualisierung entschlüsseln lassen müssen, können Sie die Datei blackbox_edit_start und blackbox_edit_end verwenden, wenn Sie "wieder in die Box einstellen" möchten.
Offensichtlich wollen wir keine geheimen Dinge wie SSL Private Schlüssel und Passwörter, die durchgesickert werden.
Nicht so offensichtlich, wenn wir "Geheimnisse" in einem VCS -Repo wie Git oder Mercurial speichern, können wir plötzlich unseren Code weniger mit anderen Personen teilen. Die Kommunikation zwischen Subtimen einer Organisation ist verletzt. Sie können auch nicht zusammenarbeiten. Entweder haben Sie sich per E -Mail an einzelne Dateien (Yuck!) E -Mail, machen ein spezielles Repo mit nur den Dateien, die Ihre Mitarbeiter (Yuck !!) benötigen, oder entscheiden, dass die Zusammenarbeit all diese Anstrengungen nicht wert ist (Yuck !!!).
Die Möglichkeit, mit Ausnahme einiger spezifischer Dateien offen und transparent zu sein, ist der Schlüssel zu der Art der Zusammenarbeit, die DevOps und moderne IT -Praktiker ausführen müssen.
make copy-install . Standard ist/usr/local (deinstallieren Sie mit make copy-uninstall ).make symlinks-install wird Symlinks der Bin-Dateien in $ prefix/bin, Standard ist/usr/lokal (deinstallieren mit make copy-uninstall ) (nützlich bei der Entwicklung)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm . Jetzt können Sie die Drehzahl über lokale Methoden verteilen. (Benötigt FPM.)make packages-deb ; Jetzt können Sie das Deb über lokale Methoden verteilen. (Benötigt FPM.)antigen bundle StackExchange/blackbox zu Ihrem .ZSHRC hinzufügenzgenom load StackExchange/blackbox zu Ihrem .ZSHRC hinzu, wo Sie Ihre anderen Plugins laden.nix-shell -p blackboxpkgin in scm-blackbox| Name: | Beschreibung: |
|---|---|
blackbox_edit <file> | Entschlüsseln, $ editor ausführen, eine Datei neu entschlüsseln |
blackbox_edit_start <file> | Entschlüsseln Sie eine Datei, damit sie aktualisiert werden kann |
blackbox_edit_end <file> | Verschlüsseln Sie eine Datei, nachdem Blackbox_edit_start verwendet wurde |
blackbox_cat <file> | Entschlüsseln und den Inhalt einer Datei anzeigen |
blackbox_view <file> | Wie Blackbox_cat, aber Rohr zu less oder $ pager |
blackbox_diff | Diff entschlüsselte Dateien gegen ihre ursprüngliche kryptische Version |
blackbox_initialize | Aktivieren Sie Blackbox für ein Git- oder HG -Repo |
blackbox_register_new_file <file> | Verschlüsseln Sie eine Datei zum ersten Mal |
blackbox_deregister_file <file> | Entfernen Sie eine Datei aus Blackbox |
blackbox_list_files | Listen Sie die von BlackBox verwalteten Dateien auf |
blackbox_list_admins | Listen Sie Administratoren auf, die derzeit für Blackbox autorisiert sind |
blackbox_decrypt_file <file> | Entschlüsseln Sie eine Datei |
blackbox_decrypt_all_files | Entschlüsseln Sie alle verwalteten Dateien (interaktiv) |
blackbox_postdeploy | Entschlüsseln Sie alle verwalteten Dateien (Stapel) |
blackbox_addadmin <gpg-key> | Fügen Sie jemanden in die Liste der Personen hinzu, die Geheimnisse verschlüsseln/entschlüsseln können |
blackbox_removeadmin <gpg-key> | Entfernen Sie jemanden aus der Liste der Personen, die Geheimnisse verschlüsseln/entschlüsseln können |
blackbox_shred_all_files | Löschen Sie sicher entschlüsselte Dateien |
blackbox_update_all_files | Entschlüsseln und dann alle Dateien erneut entschlüsseln. Nützlich nach der Änderung der Tasten |
blackbox_whatsnew <file> | Zeigen Sie, was sich im letzten Commit für eine bestimmte Datei geändert hat |
Blackbox bestimmt automatisch, welche VCs Sie verwenden und das das Richtige tut. Es verfügt über eine Plug-in-Architektur, um die Arbeit mit anderen Systemen einfach zu erweitern. Es wurde getestet, mit vielen Betriebssystemen zusammenzuarbeiten.
git - der Githg - Mercurialsvn - Subversion (Danke, Ben Drasin!)p4 - Perforce.blackbox -Verzeichnis intakt ist Um Unterstützung für ein VCS -System hinzuzufügen oder zu beheben, suchen Sie am Ende von bin/_blackbox_common.sh nach Code
Um Unterstützung für ein neues Betriebssystem hinzuzufügen oder zu beheben, suchen Sie nach den Fallanweisungen in bin/_blackbox_common.sh und bin/_stack_lib.sh und möglicherweise tools/confidence_test.sh
Blackbox kann mit Cygwin, Mingw oder WSL2 verwendet werden.
Blackbox geht davon aus, dass blackbox-admins.txt und blackbox-files.txt LF-Zeilenende haben. Windows -Benutzer sollten darauf achten, GIT oder andere Systeme so zu konfigurieren, dass diese Dateien nicht konvertiert oder "behoben" werden.
Wenn Sie Git verwenden, fügen Sie Ihre .gitattributes -Datei die folgenden Zeilen hinzu:
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
Die neueste Version von blackbox_initialize erstellt eine .gitattributes -Datei im Verzeichnis $BLACKBOXDATA (normalerweise .blackbox ) für Sie.
Die Cygwin -Unterstützung erfordert die folgenden Pakete:
Normaler Betrieb:
Entwicklung (wenn Sie Code hinzufügen und den Konfidenztest ausführen möchten)
Die Unterstützung von Mingw (mit Git for Windows) erfordert Folgendes:
Normaler Betrieb:
MINTTY anstelle von Windows Console auswählen. Sie werden Blackbox aus der Git Bash -Eingabeaufforderung ausführen.PATH=%PATH%;c:GnuWin32bin download.bat , sobald es abgeschlossen ist, installieren Sie install.batEntwicklung:
make test erforderlich sind.Wenn Sie den folgenden Fehler in WSL2 erhalten, können Sie versuchen, Ihre Umgebung mit den folgenden Anweisungen einzurichten (getestet mit Ubuntu 22.04 auf WSL2):
~/.gnupg/gpg-agent.conf auf WSL und fügen Sie die folgende Zeile hinzu: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeGPG hat viele verschiedene Möglichkeiten, eine Datei zu verschlüsseln. Blackbox verwendet den Modus, in dem Sie eine Liste von Schlüssel angeben können, mit denen die Nachricht entschlüsselt werden kann.
Wenn Sie 5 Personen ("Administratoren") haben, die in der Lage sein sollten, auf die Geheimnisse zuzugreifen, erstellt jeder einen GPG -Schlüssel und fügt ihren öffentlichen Schlüssel zum Schlüsselbund hinzu. Der zum Verschlüsseln der Datei verwendete GPG -Befehl listet alle 5 Schlüsselnamen auf. Daher kann jeder Taste die Datei entschlüsseln.
Um den Zugriff eines Menschen zu entfernen, entfernen Sie den Schlüsselnamen dieses Administrators (dh E-Mail-Adresse) aus der Liste der Administratoren und entschlüsseln Sie alle Dateien erneut. Sie können die .gpg -Datei weiterhin lesen (vorausgesetzt, sie haben Zugriff auf das Repository), können sie jedoch nicht mehr entschlüsseln.
Was ist, wenn sie eine Kopie des alten Repo beibehalten haben, bevor Sie den Zugriff beseitigt haben? Ja, sie können alte Versionen der Datei entschlüsseln. Aus diesem Grund sollten Sie, wenn ein Administrator das Team verlässt, alle Ihre Passwörter, SSL -Zertifikate usw. ändern. Sie hätten das vor Blackbox tun sollen, oder?
Warum verwenden Sie keine symmetrischen Schlüssel? Mit anderen Worten, warum sich mit all diesen GPG -Schlüsseln durcheinander bringen und stattdessen nicht alle Dateien mit einer einzigen Passphrase verschlüsseln? Ja, GPG unterstützt das, aber dann verwalten wir ein gemeinsames Passwort, das mit Problemen behaftet ist. Wenn jemand "das Team verlässt", müssten wir jedem ein neues Passwort mitgeteilt. Jetzt müssen wir nur ihren Schlüssel entfernen. Das skaliert besser.
Wie entschlüsseln automatisierte Prozesse, ohne nach einem Passwort zu fragen? GPG benötigt eine Passphrase auf einem privaten Schlüssel. Es ermöglicht jedoch die Schaffung von Subkeys, die keine Passphrase haben. Erstellen Sie für automatisierte Prozesse einen Unterschlüssel, der nur auf dem Computer gespeichert ist, der die Dateien entschlüsseln muss. Wenn beispielsweise bei Stack Exchange unser CI -System Continuous Integration (CI) eine Codeänderung in unseren Puppet Masters überschreitet, werden blackbox_postdeploy ausgeführt, um alle Dateien zu entschlüsseln. Der Benutzer, der diesen Code ausführt, verfügt über einen Unterschlüssel, der keine Passphrase benötigt. Da wir viele Meister haben, hat jeder seinen eigenen Schlüssel. Und ja, das bedeutet, dass unsere Puppenmeister sehr sicher sein müssen. Sie waren jedoch bereits sicher, weil Sie wie ein Marionettenmeister von jemandem einbrechen können, wie sie ihr Netzwerk besitzen.
Wenn Sie Puppet verwenden, warum haben Sie dann nicht nur Hiera-Eyaml verwendet? Es gibt 4 Gründe:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a oder hg commit Warten Sie ... es kann noch einfacher sein! Führen Sie blackbox_edit FILENAME aus, und es entschlüsselt die Datei in einer TEMP-Datei und ruft $EDITOR darauf an.
Ansible Vault bietet Funktionen für die Verschlüsselung von gesamten Dateien und Zeichenfolgen, die in Dateien gespeichert sind. Das Verfolgen der für die Entschlüsselung erforderlichen Passwort (n) wird jedoch von diesem Modul nicht behandelt.
Stattdessen muss man beim Ausführen des Playbooks eine Passwortdatei angeben.
Ansible Beispiel für Passwortdatei: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
Alternativ kann man dies in der Umgebungsvariablen ANSIBLE_VAULT_PASSWORD_FILE angeben.
Ganze Dateien wie SSL -Zertifikate und private Schlüssel werden genau wie reguläre Dateien behandelt. Sie entschlüsseln sie jederzeit, wenn Sie eine neue Veröffentlichung an den Marionettenmeister weitergeben.
Puppenspielbeispiel für eine verschlüsselte Datei: 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",
}
Kleine Zeichenfolgen wie Passwörter und API -Schlüssel werden in einer Hiera -Yaml -Datei gespeichert, die Sie mit blackbox_register_new_file verschlüsseln. Zum Beispiel verwenden wir eine Datei namens blackbox.yaml . Sie können mit der Funktion von Hiera () auf sie zugreifen.
Setup: Konfigurieren Sie hiera.yaml durch Hinzufügen von "Blackbox" zur Suchhierarchie:
:hierarchy:
- ...
- blackbox
- ...
In Blackbox.yaml angeben:
---
module::test_password: "my secret password"
Greifen Sie in Ihrem Puppet -Code auf das Passwort zu, wie Sie es alle Hiera -Daten tun würden:
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
Die Variable $the_password enthält "mein geheimes Passwort" und kann überall verwendet werden, wo Zeichenfolgen verwendet werden.
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
In der Befehlszeile können mehrere Dateinamen angegeben werden:
Beispiel 1: Registrieren 2 Dateien:
blackbox_register_new_file file1.txt file2.txt
Beispiel 2: Registrieren Sie alle Dateien in $DIR :
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
Das passiert ziemlich selten, aber wir haben es abgedeckt:
blackbox_deregister_file path/to/file.name.key
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
.blackbox/blackbox-admins.txt ist eine Datei, in der Benutzer Dateien entschlüsseln können. (Pedantisch ist es eine Liste der GNUPG -Schlüsselnamen, für die die Datei verschlüsselt ist.)
Um sich der Liste der Personen anzuschließen, die die Datei bearbeiten können, sind drei Schritte erforderlich. Sie erstellen eine GPG -Taste und fügen ihn zum Schlüsselring hinzu. Dann fügt jemand, der bereits Zugriff hat, zum System hinzu. Zuletzt sollten Sie Ihren Zugriff testen.
Wenn Sie noch keinen GPG -Schlüssel haben, generieren Sie eine:
gpg --gen-key
Warnung: Neue Versionen von GPG erzeugen Schlüssel, die von alten Versionen von GPG nicht verstanden werden. Wenn Sie einen Schlüssel mit einer neuen Version von GPG generieren, verursacht dies Benutzer älterer Versionen von GPG zu Problemen. Daher wird empfohlen, dass Sie entweder sicherstellen, dass jeder, der Blackbox verwendet, genau die gleiche Version von GPG hat, oder GPG -Tasten mit einer Version von GPG generieren, die so alt ist wie die älteste Version von GPG, die von jeder Verwendung von Blackbox verwendet wird.
Wählen Sie Standardeinstellungen für Verschlüsselungseinstellungen, 0 Ablauf. Wählen Sie eine sehr gute Passphrase. Bewahren Sie eine Sicherung des privaten Schlüssels an, an dem sich an einem Ort sicher ist. Halten Sie beispielsweise die Sicherungskopie auf einem USB -Laufwerk, das in Safe gesperrt ist. Oder setzen Sie es zumindest auf eine sichere Maschine mit wenig oder gar keinem Internetzugang, Vollverschlüsselung usw. Ihr Arbeitgeber hat wahrscheinlich Regeln, wie man solche Dinge speichert.
Zu Ihrer Information: Wenn das Erzeugen des Schlüssels langsam ist, liegt dies normalerweise daran, dass das System nicht genügend Entropie erzeugt. Tipp: Öffnen Sie ein anderes Fenster auf diesem Computer und führen Sie diesen Befehl aus: ls -R /
Nachdem Sie einen GPG -Schlüssel haben, fügen Sie sich als Administrator hinzu:
blackbox_addadmin KEYNAME
... wobei "Keyname" die E -Mail -Adresse ist, die in der zuvor erstellten GPG -Taste aufgeführt ist. Zum Beispiel:
blackbox_addadmin [email protected]
Wenn der Befehl erfolgreich abgeschlossen ist, werden Anweisungen zur Bekämpfung dieser Änderungen ausgegeben. Führen Sie den Befehl aus, um die Änderungen zu begehen. Es wird so aussehen:
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
Dann schieben Sie es zum Repo:
git push
or
ht push
(or whatever is appropriate)
Hinweis: Erstellen eines Rollenkontos? Wenn Sie das PubRing.gpg eines Rollenkontos hinzufügen, können Sie das Verzeichnis angeben, in dem die Datei pubRing.gpg als 2. Parameter gefunden werden kann: blackbox_addadmin [email protected] /path/to/the/dir
Fragen Sie jemanden, der bereits Zugriff auf die Datendateien hat. Dies gibt Ihnen Zugriff. Sie entschlüsseln einfach die Daten, ohne Änderungen vorzunehmen.
Vorabprüfung: Überprüfen Sie, ob die neuen Schlüssel gut aussehen.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
Untersuchen Sie beispielsweise den Schlüsselnamen (E -Mail -Adresse), um sicherzustellen, dass er den Unternehmensstandards entspricht.
Importieren Sie den Schlüsselbund in Ihren persönlichen Schlüsselbund und in Ihrer Recrypt:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
Drücken Sie die neu verkürzten Dateien:
git commit -a
git push
or
hg commit
hg push
Stellen Sie sicher, dass Sie eine Datei entschlüsseln können. (Vorschlag: Halten Sie eine Dummy -Datei in VCs, nur damit neue Personen üben können.)
Führen Sie einfach blackbox_removeadmin mit ihrem Keyname aus und können Sie erneut entschlüsseln:
Beispiel:
blackbox_removeadmin [email protected]
blackbox_update_all_files
Nach Abschluss des Befehls werden Sie daran erinnert, die Änderung einzuchecken und zu pushen.
Beachten Sie, dass ihre Schlüssel immer noch im Schlüsselring liegen, aber sie werden ungenutzt. Wenn Sie den Schlüsselring aufräumen möchten, verwenden Sie die normalen GPG -Befehle und überprüfen Sie die Datei.
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
Der Schlüsselring hat nur öffentliche Schlüssel. Es gibt keine geheimen Schlüssel zum Löschen.
Denken Sie daran, dass diese Person Zugriff auf alle Geheimnisse gleichzeitig hatte. Sie hätten eine Kopie machen können. Um vollständig sicher zu sein, sollten Sie alle Passwörter ändern, neue SSL -Schlüsseln generieren und so weiter, wie wenn jemand, der einen privilegierten Zugriff hatte, eine Organisation verlässt.
Die Validierung der Vertrauenswürdigkeit von Schlüssel ist eine Aufgabe, die von Blackbox nicht erledigt werden kann. Dies ist ein völlig externes Thema, das manuell (z. Abgesehen von den "gemeinsamen" Vorteilen eines Vertrauensnetzes (siehe hier oder hier, z. B.), wird auch mehrere Fehler verhindert.
Historisch gesehen hat Blackbox ein "Vertrauen jedes Schlüssel" -Modell verwendet und durchgesetzt, aber dies hat sich geändert! Die Entscheidung, ob und wie die PGP/GPG -Vertrauensmodelle verwendet werden, bleibt dem Benutzer durch Konfiguration (oder von der Standardeinstellung PGP/GPG) überlassen.
Bei der Aktualisierung von Blackbox -Leuten kann es sein, dass sie auf funktionale Probleme stoßen, wenn sie sich noch nicht mit der Vertrauensbarkeit der Tasten befasst haben, die sie verwenden. Es ist der richtige Zeitpunkt, um dies zu tun und jetzt Ihr Vertrauensnetz aufzubauen!
Wenn Sie über einen externen Workflow verfügen, der sicherstellt, dass die Integrität der Schlüsseln Blackbox verwendet, sollten Sie die PGP/GPG -Trust -Modelle deaktivieren und sich auf diesen Workflow verlassen.
Dies kann erreicht werden, indem "immer" Vertrauensmodell "deklariert wird, entweder durch Übergabe des Befehlszeilenparameters- --trust-model=always an Ihre PGP/GPG-Binärdatei bei der Verwendung von Blackbox (durch Definieren eines Alias oder die Verwendung der Umgebungsvariablen (z. B. GPG="gpg2 --trust-model=always" ) oder eine Kombination aus beiden) oder durch Einstellen trust-model always in Ihrem gpg.conf (beachten Sie, dass dies das Web of Trust überall deaktiviert, nicht nur für Blackbox).
Warnung: Es ist stark benachteiligt, überhaupt keine wichtige Validierung zu verwenden! Dies eröffnet verschiedene Möglichkeiten, um die Vertraulichkeit Ihrer verschlüsselten Geheimnisse zu umgehen!
BlackBox speichert seine Konfigurationsdaten im Subdadumgebungsverzeichnis .blackbox . Ältere Repos verwenden keyrings/live . Für die Rückwärtskompatibilität funktioniert auch.
Alle Dokumentation bezieht sich auf .blackbox .
Sie können ein altes Repo konvertieren, indem Sie einfach das Verzeichnis umbenennen:
mv keyrings/live .blackbox
rmdir keyrings
Es gibt keinen technischen Grund, alte Repos umzuwandeln, außer dass es für die Benutzer weniger verwirrend ist.
Diese Änderung wurde in Commit 60E782A0, Release V1.20180615 vorgenommen.
Die Details:
$BLACKBOXDATA . Wenn diese Umgebungsvariable festgelegt ist, ist dies das verwendete Verzeichnis. Wenn es ein nicht vorhandenes Verzeichnis auflistet, druckt Blackbox einen Fehler und beendet.$BLACKBOXDATA nicht festgelegt ist: (Dies ist der typische Anwendungsfall)keyrings/live versuchen und es benutzen, wenn es existiert..blackbox verwendet. Wenn keine .blackbox vorliegt, druckt Blackbox einen Fehler und beendet.Überblick:
Um einem Git- oder Mercurial -Repo "Blackbox" hinzuzufügen, müssen Sie Folgendes tun:
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
Sie möchten Blackboxs "Bin" -Verzeichnis in Ihren Weg einbeziehen:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
Wenn Sie Antigen verwenden, wird dieses Repository dieses antigen bundle StackExchange/blackbox heruntergeladen und Ihrem $ -Path.
Befolgen Sie die Anweisungen für "Wie kann man einen neuen Benutzer in das System einbeziehen?". Nur Schritt 1 machen.
Sobald dies erledigt ist, ist eine gute Idee, um das System zu testen, indem sichergestellt wird, dass eine Datei zum System hinzugefügt werden kann (siehe "So einschreiben Sie eine neue Datei in das System?"), Und ein anderer Benutzer kann die Datei entschlüsseln.
Machen Sie eine neue Datei und registrieren Sie sie:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
Entschlüsseln:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
Neurangigen Sie es erneut:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
Sie sollten nur foo.txt.gpg sehen, da foo.txt verschwunden sein sollte.
Der nächste Schritt besteht darin, foo.txt.gpg zu begehen und sicherzustellen, dass ein anderer Benutzer den Inhalt der Datei überprüfen, anzeigen und ändern kann. Das bleibt als Übung für den Leser. Wenn Sie ein Risiko eingehen möchten, begehen Sie nicht foo.txt.gpg und löschen Sie es stattdessen.
dh so kann ein Marionettenmeister Zugriff auf die unverschlüsselten Daten haben.
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
Ein automatisierter Benutzer (ein "Rollenkonto") ist einer, der in der Lage sein muss, ohne Passphrase zu entschlüsseln. Im Allgemeinen möchten Sie dies für den Benutzer tun, der die Dateien vom Repo zum Master zieht. Dies kann mit Jenkins CI oder einem anderen CI -System automatisiert werden.
GPG -Tasten müssen eine Passphrase haben. Passphrasen sind jedoch auf Subkeys optional. Daher erstellen wir einen Schlüssel mit einer Passphrase und erstellen dann einen Unterschlüssel ohne Passphrase. Da der Unterschlüssel sehr leistungsfähig ist, sollte er auf einer sehr sicheren Maschine erstellt werden.
Es gibt noch einen Haken. Das Rollenkonto kann die Dateien wahrscheinlich nicht in Git/Mercurial überprüfen. Es hat wahrscheinlich nur schreibgeschützte Zugriff auf das Repo. Das ist eine gute Sicherheitspolitik. Dies bedeutet, dass das Rollenkonto nicht verwendet werden kann, um die öffentlichen Subty -Bits in das Repo hochzuladen.
Daher erstellen wir den Schlüssel/Unterschlüssel auf einer sicheren Maschine wie Sie selbst. Von dort aus können wir die öffentlichen Teile in das Repo einlassen. Auch aus diesem Konto werden wir die Teile exportieren, die das Rollenkonto benötigt, sie dorthin kopieren, wo das Rollenkonto auf sie zugreifen kann, und sie als Rollenkonto importieren.
Protip: Wenn Sie gebeten werden, Entropie zu generieren, sollten Sie dies in einem anderen Fenster auf derselben Maschine ausführen: sudo dd if=/dev/sda of=/dev/null
Für den Rest dieses Dokuments müssen Sie die folgenden Substitutionen vornehmen:
Hinweis: Dies sollte automatisierter/geschrieben sein. Patches willkommen.
Erstellen Sie auf SecureHost die Schlüssel des Puppet Master:
$ 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]
Hinweis: Verwenden Sie anstelle einer echten E -Mail -Adresse den Benutzernamen@fqdn des Hosts, auf dem der Schlüssel verwendet wird. Wenn Sie dieses Rollenkonto für viele Maschinen verwenden, sollte jeder seinen eigenen Schlüssel haben. Durch die Verwendung des FQDN des Hosts können Sie wissen, welcher Schlüssel der ist. In diesem Dokument bezeichnen wir den username@fqdn als $ keyname
Speichern Sie die Passphrase irgendwo sicher!
Erstellen Sie einen Unterschlüssel mit kein Passwort:
$ 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
Exportieren Sie nun dieses Verzeichnis sicher in Newmaster:
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
Empfangen Sie bei Newmaster die neue GNUPG -Konfiguration:
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
Fügen Sie wieder auf SecureHost die neue E-Mail-Adresse zu .blackbox/Blackbox-admins.txt hinzu:
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
Stellen Sie sicher, dass Secring.gpg eine Datei mit Nulllänge ist. Wenn dies nicht der Fall ist, haben Sie dem Schlüsselring irgendwie einen privaten Schlüssel hinzugefügt. Fangen Sie vor.
cd .blackbox
ls -l secring.gpg
Begehen Sie die jüngsten Änderungen:
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
Regenerieren Sie alle verschlüsselten Dateien mit dem neuen Schlüssel:
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
Importieren Sie bei Newmaster die Schlüssel und entschlüsseln Sie die Dateien:
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: Wenn Sie "GPG: Entschlüsselung fehlgeschlagen haben: Keine geheimen Schlüssel", haben Sie vergessen, Blackbox.yaml mit dem neuen Schlüssel erneut zu decrypt.
Löschen Sie Ihre Dateien auf SecureHost sicher:
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
Setzen Sie auch alle anderen temporären Dateien, die Sie möglicherweise erstellt haben.
Wenn jemandes Schlüssel bereits abgelaufen ist, wird Blackbox nicht mehr verschlüsseln. Sie sehen diesen Fehler:
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
Sie können auch Schlüssel erkennen, die ablaufen, indem Sie diesen Befehl ausgeben und die "abgelaufenen" Daten manuell überprüfen: Daten:
gpg --homedir=.blackbox --list-keys
oder ... Listen Sie UIDs auf, die innerhalb von 1 Monat ab heute ausfallen: (Warnung: Dies listet auch Schlüssel ohne Ablaufdatum auf)
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
So ersetzen Sie den Schlüssel:
WARNUNG: Dieser Prozess löscht unverschlüsselte Dateien, die Sie gerade bearbeiten. Kopieren Sie sie an anderer Stelle und stellen Sie die Änderungen wieder her.
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
Alle Dateien, die im ersten Schritt vorübergehend kopiert wurden, um nicht überschrieben zu werden, können jetzt wieder kopiert und mit dem Befehl blackbox_edit_end neu verkleidet werden.
(Vielen Dank an @Chishaku für die Suche nach einer Lösung für dieses Problem!)
Es ist möglich, Git zu sagen, dass er Versionen der Datei entschlüsselt, bevor sie über git diff oder git log ausgeführt werden. Um dies zu erreichen:
.gitattributes oben im Git -Repository hinzu: *.gpg diff=blackbox
.git/config hinzu: [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
Und jetzt zeigt Befehle wie git log -p file.gpg ein schönes Protokoll der Änderungen in der verschlüsselten Datei.
gpg: filename: skipped: No public key -Normalerweise bedeutet dies ein Element in .blackbox/blackbox-admins.txt , der nicht der Name des Schlüssels ist. Entweder wurde etwas Ungültiges eingefügt (wie ein Dateiname anstelle eines Benutzernamens) oder ein Benutzer hat die Organisation verlassen und ihr Schlüssel wurde aus der Schlüsselbund entfernt, aber sein Name wurde jedoch nicht aus der Blackbox-Adminen-TXT-Datei entfernt.
gpg: decryption failed: No secret key -bedeutet normalerweise, dass Sie die Datei mit dem neuen Schlüssel erneut entschlüsseln.
Error: can't re-encrypt because a key has expired. - Der Schlüssel eines Benutzers ist abgelaufen und kann nicht mehr verwendet werden, um sie zu verschlüsseln. Befolgen Sie die Tipps abgelaufener Schlüsseln.
Zu Ihrer Information: Ihr Repo kann keyrings/live anstelle von .blackbox verwenden. Siehe "Wo wird die Konfiguration gespeichert?"
Wenn die Dateien aus einem Repo kopiert werden, können sie immer noch entschlüsselt und bearbeitet werden. Offensichtlich bearbeitet, Änderungen an Schlüssel und so werden verloren gehen, wenn sie außerhalb des Repo vorgenommen werden. Beachten Sie auch, dass Befehle am wahrscheinlichsten nur dann funktionieren, wenn sie aus dem Basisverzeichnis ausgeführt werden (dh der übergeordnete zum .blackbox -Verzeichnis).
Die folgenden Befehle wurden außerhalb eines Repo getestet:
blackbox_postdeployblackbox_edit_startblackbox_edit_end Die aktuelle Implementierung speichert die Blackbox in /keyrings am Wurzel des gesamten Repo. Dies führt zu einem Problem zwischen Umgebungen mit unterschiedlichen Wurzeln (dh in der Produktion ausgleichen / auf Entwicklung oder /releases/foo ). Um dies zu umgehen, können Sie export BLACKBOX_REPOBASE=/path/to/repo und eine bestimmte Basis für Ihr Repo festlegen.
Dies wurde ursprünglich für Git geschrieben und unterstützt ein zweiphasige Komitee, in dem commit ein lokales Komitee ist und "Push" die Änderung stromaufwärts an den Versionskontrollserver sendet, wenn etwas mit dem System registriert oder derenegistriert ist. Die aktuelle Implementierung wird sofort eine Datei (auf dem Upstream -Subversion -Server) commit , wenn Sie einen Befehl blackbox_* ausführen.
In einigen Situationen müssen Teammitglieder oder automatisierte Rollen GPG 2.x neben der System GPG Version 1.x installieren, um die GPG -Version des Teams zu treffen. Auf Ubuntu 16 können Sie apt-get install gnupg2 , das den binären GPG2 installiert. Wenn Sie diesen GPG2 -Binary verwenden möchten, führen Sie jeden Befehl Blackbox mit gpg = gpg2 aus.
Zum Beispiel:
GPG=gpg2 blackbox_postdeploy
Wir begrüßen Fragen, Fehlerberichte und Feedback!
Der beste Ort, um zu beginnen, ist, sich der Blackbox-Project-Mailingliste anzuschließen und dort zu fragen.
Fehler werden hier in Github verfolgt. Bitte zögern Sie nicht, Fehler selbst zu melden.
Code -Einreichungen sind gerne begrüßt! Der Code ist ziemlich einfach zu lesen.
Holen Sie sich den Code:
git clone [email protected]:StackExchange/blackbox.git
Testen Sie Ihre Änderungen:
make confidence
Dies führt durch eine Reihe von Systemtests. Es erstellt ein Repo, verschlüsselt Dateien, entschlüsselt Dateien usw. Sie können diese Tests durchführen, um zu überprüfen, ob die von Ihnen vorgenommenen Änderungen nichts gebrochen haben. Sie können diese Tests auch verwenden, um zu überprüfen, ob das System mit einem neuen Betriebssystem arbeitet.
Bitte senden Sie Tests mit Codeänderungen:
Der beste Weg, um Blackbox zu wechseln, ist die testgetriebene Entwicklung. Fügen Sie zunächst einen Test zu tools/confidence.sh hinzu. Dieser Test sollte scheitern und die Notwendigkeit der Änderung demonstrieren, die Sie vornehmen werden. Beheben Sie dann den Fehler oder fügen Sie die gewünschte Funktion hinzu. Wenn Sie fertig sind, sollte make confidence alle Tests bestehen. Die PR, die Sie einreichen, sollte Ihren Code sowie den neuen Test enthalten. Auf diese Weise sammeln sich die Konfidenztests an, wenn das System wächst, da wir wissen, dass zukünftige Änderungen nicht alte Merkmale brechen.
Hinweis: Die Tests werden derzeit "Git" annehmen und wurden nur auf CentOS, Mac OS X und Cygwin getestet. Patches willkommen!
Hier sind weitere Open -Source -Pakete, die Blackbox ähnlich machen. Wenn Sie sie besser mögen als Blackbox, verwenden Sie sie bitte.
Git-Crypt hat die beste Git-Integration. Sobald es eingerichtet ist, ist es für die Benutzer nahezu transparent. Es funktioniert jedoch nur mit Git.
Dieser Inhalt wird unter der MIT -Lizenz veröffentlicht. Siehe die lizenz.txtdatei.
