blackbox
v1.20220610
秘密をVCSリポジトリ（つまり、git、mercurial、subversion、またはperforce）に安全に保存します。これらのコマンドにより、GNUプライバシーガード（GPG）がリポジトリで特定のファイルを暗号化できるようにするため、リポジトリで「安静時に暗号化」されます。ただし、スクリプトにより、表示または編集する必要があるときにスクリプトを簡単に復号化し、生産で使用するためにそれらを復号化できます。もともとPuppetのために書かれたBlackboxは、GitまたはMercurial Repositoryで動作するようになりました。
警告：このプロジェクトの目標は、 gpgめぐるシンプルなラッパーになることです。そうすれば、あなたとあなたの同僚は、それらのすべての不可解で混乱する旗を覚えておく必要はありません。すべての問題を解決したり、多数のファイルをサポートする洗練された暗号化システムであることを意図したものではありません。理想的なユースケースは、Conver、AWS KMS、Azure Key Vault、GCP KMSなどの安全なサービスで秘密を維持することです。次に、そのシステムにアクセスするために必要なAPIキーを安全に保存するためにBlackboxを使用します。そうすれば、単一の小さなファイルを暗号化しています。それ以上の機能のための機能要求は拒否されます。 「エンタープライズ機能」を期待したり要求したりしないでください。これがあなたを失望させた場合は、https：//www.agwa.name/projects/git-cryptなどの競合プロジェクトを検討してください
スライドプレゼンテーション（古いリリースについて）がスライドシェアにあります。
メーリングリストに参加してください：https：//groups.google.com/d/forum/blackbox-project
VCSリポジトリ（つまり、GitまたはMercurial Repo）があり、特定のファイルにパスワードやSSLプライベートキーなどの秘密が含まれているとします。多くの場合、人々はそのようなファイルを保存するだけです。それは安全ではありません。
Blackboxを使用すると、これらのファイルはGPGを使用して暗号化されて保存されます。適切なGPGキーを持たずにVCSリポジトリへのアクセスは、ファイルを持つことは価値がありません。 GPGキーを安全に保つ限り、信頼できないサーバーにVCSリポジトリを保存することを心配する必要はありません。ヘック、たとえあなたがあなたのサーバーを信頼していても、あなたはそのサーバーのバックアップを行う人々、またはバックアップテープを処理する人々を信頼する必要はありません！
すべてのファイルに1つのGPGパスフレーズではなく、アクセスしている各人には、システムに独自のGPGキーがあります。任意のファイルは、GPGキーを持っている人は誰でも復号化できます。このようにして、1人が会社を去る場合、アクセスして全員に新しいパスワードを伝える必要はありません。アクセスしなくなるはずの1つのキーを無効にするだけです。これを行うプロセスは、2つのコマンドを実行するのと同じくらい簡単です（1つのキーを無効にするために1つ、すべてのファイルを再クリップするために1つ。）
自動化されたプロセスでは、多くの場合、すべての復号化されたファイルにアクセスする必要があります。これも簡単です。たとえば、gitが人形ファイルに使用されているとします。マスターは、すべてのファイルの復号化されたバージョンにアクセスする必要があります。 Puppet MasterのGPGキー（または、新しいファイルをPuppet Masterにプッシュするロールアカウント）のGPGキーを設定し、ユーザーにファイルが更新された後にblackbox_postdeployを実行させるだけです。
GPGキーがない場合は、次のような手順を使用して設定します。GPGキーを設定します。
今、あなたは行く準備ができています。
git、mercurial、subversion、またはperforceリポジトリへのcdとblackbox_initializeを実行します。
ファイルを暗号化する場合は、 blackbox_register_new_file実行すると、完了します。
blackbox_addadminとblackbox_removeadminを使用してキーを追加して削除します。
ファイルを表示および/または編集するには、 blackbox_editを実行します。これにより、ファイルを復号化し、$ Editor Environment変数によって指定されているもので開きます。
エディターを閉じると、ファイルが再び自動的に暗号化され、一時的なプレーンテキストファイルが細断されます。
更新中にファイルを復号化する必要がある場合は、 blackbox_edit_start使用して、「ボックスに戻す」場合にファイルとblackbox_edit_end復号化できます。
明らかに、SSLのプライベートキーやパスワードなどの秘密のものを漏らしたくありません。
GitやMercurialなどのVCSリポジトリに「Secrets」を保存するとき、それほど明らかではありませんが、突然、コードを他の人と共有することができません。組織のサブチーム間のコミュニケーションは傷つきます。協力することもできません。周りに個々のファイルに電子メールを送信していることに気付くか（Yuck！）、コラボレーター（Yuck !!）が必要とするファイルだけで特別なレポを作成するか、コラボレーションがすべての努力に値しないと判断します（Yuck !!!）。
いくつかの特定のファイルを除いて、コードについてオープンで透明性を持つ能力は、DevopsとModern IT Practitionersが行う必要がある種類のコラボレーションの鍵です。
make copy-install 、ビンファイルmake copy-uninstall $プレフィックス/ビンにコピーします。make symlinks-installビンファイルのシンリンクmake copy-uninstall $プレフィックス/ビンにします。sudo port install vcs_blackboxbrew install blackboxmake packages-rpmを使用してRPMを作成します。これで、ローカルメソッドを介してRPMを配布できます。 （FPMが必要です。）make packages-deb介してDebを作成します。これで、ローカルメソッドを介してDEBを配布できます。 （FPMが必要です。）antigen bundle StackExchange/blackboxを.zshrcに追加するzgenom load StackExchange/blackbox .zshrcに追加して、他のプラグインをロードします。nix-shell -p blackboxpkgin in scm-blackbox| 名前： | 説明： |
|---|---|
blackbox_edit <file> | Decrypt、$ Editorを実行し、ファイルを再クリップします |
blackbox_edit_start <file> | 更新できるようにファイルを復号化します |
blackbox_edit_end <file> | Blackbox_edit_startが使用された後、ファイルを暗号化します |
blackbox_cat <file> | ファイルの内容を復号化して表示します |
blackbox_view <file> | Blackbox_catのように、ただしパイプはlessまたは$ポケットベルになります |
blackbox_diff | DIFF Decryptedファイルは、元の暗号化バージョンに対して |
blackbox_initialize | GITまたはHGリポジトリのBlackboxを有効にします |
blackbox_register_new_file <file> | ファイルを初めて暗号化します |
blackbox_deregister_file <file> | Blackboxからファイルを削除します |
blackbox_list_files | Blackboxが管理するファイルをリストします |
blackbox_list_admins | 現在、Blackboxで承認されている管理者をリストしています |
blackbox_decrypt_file <file> | ファイルを復号化します |
blackbox_decrypt_all_files | すべてのマネージドファイル（インタラクティブ）を復号化する |
blackbox_postdeploy | すべての管理されたファイル（バッチ）を復号化する |
blackbox_addadmin <gpg-key> | 秘密を暗号化/解読できる人のリストに誰かを追加する |
blackbox_removeadmin <gpg-key> | 秘密を暗号化/解読できる人のリストから誰かを削除します |
blackbox_shred_all_files | 復号化されたファイルを安全に削除します |
blackbox_update_all_files | 次に、すべてのファイルを再クリップします。キーが変更された後に便利です |
blackbox_whatsnew <file> | 特定のファイルの最後のコミットで変更されたものを表示する |
Blackboxは、使用しているVCを自動的に決定し、正しいことを行います。他のシステムとの連携に簡単に拡張できるようにするプラグインアーキテクチャがあります。多くのオペレーティングシステムで動作するようにテストされています。
githg -Mercurialsvn -Subversion（ありがとう、ベンドラシン！）p4 -Perforce.blackboxディレクトリが無傷の場合、ファイルはレポの外側で復号化できます VCSシステムのサポートを追加または修正するには、 bin/_blackbox_common.shの最後にコードを探してください
新しいオペレーティングシステムのサポートを追加または修正するには、 bin/_blackbox_common.shとbin/_stack_lib.sh tools/confidence_test.sh
Blackboxは、Cygwin、Mingw、またはWSL2で使用できます。
Blackboxは、 blackbox-admins.txtとblackbox-files.txtにLFラインエンディングがあると想定しています。 Windowsユーザーは、これらのファイルを変換または「修正」しないようにGITまたは他のシステムを構成するように注意する必要があります。
gitを使用する場合は、 .gitattributesファイルに次の行を追加します。
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
blackbox_initializeの最新バージョンは、 $BLACKBOXDATAディレクトリ（通常.blackbox ）に.gitattributesファイルを作成します。
Cygwinサポートには、次のパッケージが必要です。
通常の操作：
開発（コードを追加して自信テストを実行したい場合）
Mingw（Windows用のGitが付属）サポートには次のものが必要です。
通常の操作：
MINTTY選択してください。 Git BashプロンプトからBlackboxを実行することになります。download.batはinstall.batを完了したら、それらのツールのパスをパスに追加します（ex： PATH=%PATH%;c:GnuWin32bin ）発達：
make test実行するために追加のパッケージが必要かどうかをお知らせください）WSL2で次のエラーが発生した場合は、次の指示で環境をセットアップしてみることができます（WSL2でUbuntu 22.04でテスト）：
~/.gnupg/gpg-agent.conf wslで編集し、次の行を追加します： pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeGPGには、ファイルを暗号化するさまざまな方法があります。 Blackboxは、メッセージを解読できるキーのリストを指定できるモードを使用します。
秘密にアクセスできるはずの5人（「管理者」）がいる場合、それぞれがGPGキーを作成し、キーチェーンに公開キーを追加します。ファイルを暗号化するために使用されるGPGコマンドは、5つのキー名すべてをリストします。したがって、1キーはすべてファイルを復号化できます。
誰かのアクセスを削除するには、管理者のキー名（すなわち、メールアドレス）を管理者のリストから削除し、すべてのファイルを再現します。 .gpgファイルを読み取ることができます（リポジトリにアクセスできると仮定します）が、これ以上復号化することはできません。
アクセスを削除する前に古いリポジトリのコピーを保管した場合はどうなりますか？はい、ファイルの古いバージョンを復号化できます。これが、管理者がチームを去ったときに、すべてのパスワード、SSL証明書などを変更する必要がある理由です。 Blackboxの前にそれをしているはずですよね？
対称キーを使用してみませんか？言い換えれば、なぜこのすべてのGPGの重要なものを台無しにし、代わりにすべてのファイルを単一のパスフレーズで暗号化するだけではありません。はい、GPGはそれをサポートしていますが、その後、共有パスワードを管理していますが、これには問題があります。誰かが「チームを去る」場合、新しいパスワードを全員に通信する必要があります。今、私たちは彼らのキーを削除する必要があります。これはより良いスケールです。
パスワードを要求せずに、自動化されたプロセスはどのように復号化されますか？ GPGには、秘密鍵のパスフレーズが必要です。ただし、パスフレーズのないサブキーの作成が可能になります。自動化されたプロセスの場合、ファイルを解読する必要があるマシンにのみ保存されているサブキーを作成します。たとえば、Stack Exchangeでは、連続統合（CI）システムがパペットマスターにコードの変更をプッシュすると、 blackbox_postdeploy実行してすべてのファイルを復号化します。このコードを実行するユーザーには、パスフレーズを必要としないサブキーがあります。私たちには多くのマスターがいるので、それぞれに独自の鍵があります。そして、はい、これは私たちの操り人形マスターが非常に安全でなければならないことを意味します。しかし、彼らはすでに安全でした。
人形を使用している場合、なぜHiera-eyamlを使用しなかったのですか？ 4つの理由があります：
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -aまたはhg commit待って...それよりもさらに簡単になる可能性があります！ blackbox_edit FILENAME実行すると、ファイルを一時ファイルに復号化し、 $EDITORを呼び出し、編集者が閉じた後に再び暗号化します。
Ansible Vaultは、ファイル全体とファイル内に保存されている文字列の両方を暗号化する機能を提供します。ただし、復号化に必要なパスワードを追跡することは、このモジュールでは処理されません。
代わりに、プレイブックを実行するときにパスワードファイルを指定する必要があります。
パスワードファイルのAnsible例： my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
または、これをANSIBLE_VAULT_PASSWORD_FILE環境変数で指定することができます。
SSL CERTやプライベートキーなどのファイル全体は、通常のファイルのように扱われます。新しいリリースをPuppet Masterにプッシュするたびに、それらを復号化します。
暗号化されたファイルの人形の例： 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",
}
パスワードやAPIキーなどの小さな文字列は、 blackbox_register_new_fileで暗号化するHiera yamlファイルに保存されます。たとえば、 blackbox.yamlというファイルを使用します。 Hiera（）関数を使用してアクセスできます。
セットアップ：検索階層に「ブラックボックス」を追加して、 hiera.yamlを構成します。
:hierarchy:
- ...
- blackbox
- ...
blackbox.yamlで指定します：
---
module::test_password: "my secret password"
人形コードでは、hieraデータと同様にパスワードにアクセスしてください。
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
変数$the_passwordは「私の秘密のパスワード」が含まれ、どこでも使用できます。
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
コマンドラインで複数のファイル名を指定できます。
例1：登録2ファイル：
blackbox_register_new_file file1.txt file2.txt
例2：すべてのファイルを$DIRに登録します：
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
これはまれに起こりませんが、私たちはそれをカバーしています：
blackbox_deregister_file path/to/file.name.key
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
.blackbox/blackbox-admins.txtは、ファイルを解読できるユーザーをリストするファイルです。 （もっと慣習的には、ファイルが暗号化されているGNUPGキー名のリストです。）
ファイルを編集できる人のリストに参加するには、3つのステップが必要です。 GPGキーを作成し、キーリングに追加します。その後、すでにアクセスしている人がシステムに追加します。最後に、アクセスをテストする必要があります。
まだGPGキーを持っていない場合は、次のように生成する方法は次のとおりです。
gpg --gen-key
警告：GPGの新しいバージョンは、GPGの古いバージョンでは理解されていないキーを生成します。 GPGの新しいバージョンでキーを生成すると、GPGの古いバージョンのユーザーに問題が発生します。したがって、Blackboxを使用している全員がGPGとまったく同じバージョンを持っていることを保証するか、GPGのバージョンを使用してGPGキーを生成することをお勧めします。
暗号化設定のデフォルトを選択し、0の有効期限が切れます。非常に良いパスフレーズを選びます。秘密鍵のバックアップを安全に保存します。たとえば、安全にロックされているUSBドライブにバックアップコピーを保管してください。または、少なくとも、インターネットアクセス、フルディスク暗号化などがほとんどまたはまったくない安全なマシンに置いてください。雇用主は、おそらくそのようなものを保存する方法についてのルールを持っています。
FYI：キーを生成するのが遅い場合、これは通常、システムが十分なエントロピーを生成していないためです。ヒント：そのマシンで別のウィンドウを開き、このコマンドを実行します： ls -R /
GPGキーができたので、管理者として自分自身を追加してください。
blackbox_addadmin KEYNAME
...ここで、「keyname」は、以前に作成したGPGキーにリストされているメールアドレスです。例えば：
blackbox_addadmin [email protected]
コマンドが正常に完了すると、これらの変更をコミットする方法に関する指示は出力されます。変更をコミットするために与えられたコマンドを実行します。次のようになります：
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
次に、リポジトリに押し込みます。
git push
or
ht push
(or whatever is appropriate)
注：ロールアカウントの作成？ロールアカウントのpubring.gpgを追加する場合、pubring.gpgファイルが2番目のパラメーターとして見つけることができるディレクトリを指定できます： blackbox_addadmin [email protected] /path/to/the/dir
すでにアクセスできる人にデータファイルを再クリックするように尋ねます。これにより、アクセスできます。変更を加えることなく、データを解読して再暗号化するだけです。
プレチェック：新しいキーが見栄えが良くなることを確認します。
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
たとえば、キー名（メールアドレス）を調べて、企業の基準に適合していることを確認します。
キーチェーンをパーソナルキーチェーンにインポートし、recrypt：
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
再暗号化されたファイルを押します：
git commit -a
git push
or
hg commit
hg push
ファイルを復号化できることを確認してください。 （提案：新しい人が練習するためだけにダミーファイルをVCSに保管してください。）
KeyNameを使用してblackbox_removeadminを実行してから再クリップを実行するだけです。
例：
blackbox_removeadmin [email protected]
blackbox_update_all_files
コマンドが完了すると、変更をチェックインしてプッシュするリマインダーが与えられます。
キーはまだキーリングにあることに注意してください。しかし、彼らは未使用になります。キーリングをクリーンアップしたい場合は、通常のGPGコマンドを使用してファイルをチェックインします。
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
キーリングにはパブリックキーのみがあります。削除する秘密の鍵はありません。
この人は一度にすべての秘密にアクセスできることを忘れないでください。彼らはコピーを作ったかもしれません。したがって、完全に安全にするには、すべてのパスワードを変更し、新しいSSLキーを生成するなど、特権アクセスを持っている人が組織を離れるときと同じように。
キーの信頼性を検証することは、Blackboxでは達成できないタスクです。これは、手動で対処する必要がある完全に外部のトピックです（たとえば、キーの生成/管理と同じ方法）または専用のメカニズム（対応するワークフローを備えた会社CA）によって。信頼のWebの「一般的な」利点（ここまたはこちらを参照）を除いて、いくつかのエラーも防止します。
歴史的に、Blackboxは「すべてのキー」モデルを「信頼する」モデルを使用して実施していましたが、これは変更されました！これで、PGP/GPG Trustモデルを使用するかどうか、どのように使用するかは、構成によって（またはPGP/GPGデフォルト）によってユーザーに任されています。
ブラックボックスを更新すると、使用しているキーの信頼性にまだ対処していない場合、人々の人々は機能的な問題に遭遇する可能性があります。そうするのは適切な時期であり、今あなたの信頼のウェブを構築しました！
Blackboxが使用するキーの整合性を保証する外部ワークフローがある場合は、PGP/GPG Trustモデルを無効にし、このワークフローに依存する場合があります。
これは、Blackboxを使用する場合（エイリアスを定義するか、環境変数を使用することにより（ GPG="gpg2 --trust-model=always"を使用する）、コマンドラインパラメーター--trust-model=always PGP/GPGバイナリに渡すことにより、「Trust Model Always」を宣言することで実現できます。 GPG="gpg2 --trust-model=always" ）または両方の組み合わせ）またはgpg.confにtrust-model always設定することにより（これにより、Blackboxだけでなく、どこでもWebのWebを無効にします）。
警告：重要な検証をまったく使用しないことは強く不利です！これにより、暗号化された秘密の機密性をバイパスするさまざまな方法が開かれます！
Blackboxは、構成データを.blackbox Subdirectoryに保存します。古いレポはkeyrings/liveを使用します。後方互換性の場合、どちらも機能します。
すべてのドキュメントは.blackboxを指します。
ディレクトリの名前を変更するだけで、古いリポジトリを変換できます。
mv keyrings/live .blackbox
rmdir keyrings
ユーザーにはあまり混乱していないことを除いて、古いレポを変換する技術的な理由はありません。
この変更は、v1.20180615のリリース60E782A0で行われました。
詳細：
$BLACKBOXDATAをチェックします。この環境変数が設定されている場合、これは使用されるディレクトリです。存在しないディレクトリをリストすると、Blackboxはエラーを印刷して終了します。$BLACKBOXDATAが設定されていない場合：（これは典型的なユースケースです）keyrings/live試して、存在する場合は使用します。.blackboxが使用されます。 .blackbox存在しない場合、Blackboxはエラーを印刷して終了します。概要：
GitまたはMercurial Repoに「Blackbox」を追加するには、次のことを行う必要があります。
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
あなたはあなたのパスにBlackboxの「Bin」ディレクトリを含めたいと思うでしょう：
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
抗原を使用している場合は、 antigen bundle StackExchange/blackbox .zshrcに追加すると、このリポジトリをダウンロードして$パスに追加します。
「新しいユーザーをシステムに教化する方法」の指示に従ってください。ステップ1のみを行います。
それが完了したら、ファイルをシステムに追加できるようにすることでシステムをテストすることをお勧めします（「新しいファイルをシステムに登録する方法」を参照）、別のユーザーがファイルを解読できます。
新しいファイルを作成して登録します。
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
それを復号化する：
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
再暗号化：
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
foo.txt.gpg foo.txtがなくなるので、foo.txt.gpgのみを見る必要があります。
次のステップは、 foo.txt.gpgをコミットし、別のユーザーがファイルの内容をチェックアウト、表示、変更できることを確認することです。それは読者のための演習として残されています。リスクを冒したいと思う場合は、 foo.txt.gpgコミットして代わりに削除しないでください。
IEこれは、パペットマスターが暗号化されていないデータにアクセスできる方法です。
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
自動化されたユーザー（「ロールアカウント」）は、パスフレーズなしで復号化できる必要があるユーザーです。一般に、リポジトリからマスターにファイルをプルするユーザーのためにこれを行う必要があります。これは、Jenkins CIまたは他のCIシステムで自動化できます。
GPGキーにはパスフレーズが必要です。ただし、パスフレーズはサブキーでオプションです。したがって、パスフレーズを使用してキーを作成し、パスフレーズなしでサブキーを作成します。サブキーは非常に強力であるため、非常に安全なマシンで作成する必要があります。
別のキャッチがあります。ロールアカウントは、おそらくgit/mercurialにファイルをチェックすることはできません。おそらく、リポジトリへの読み取り専用アクセスしかありません。それは良いセキュリティポリシーです。これは、ロールアカウントを使用してサブキーパブリックビットをリポジトリにアップロードできないことを意味します。
したがって、安全なマシンにキー/サブキーを自分自身として作成します。そこから、公開部分をリポジトリにコミットできます。また、このアカウントから、役割アカウントが必要とする部品をエクスポートし、ロールアカウントがアクセスできる場所にコピーし、役割アカウントとしてインポートします。
Protip：エントロピーを生成するように求められた場合、これを別のウィンドウで同じマシンで実行することを検討してください： sudo dd if=/dev/sda of=/dev/null
このドキュメントの残りの部分については、次の代替を作成する必要があります。
注：これは、より自動化/スクリプト化する必要があります。パッチを歓迎します。
SecureHostで、Puppet Master's Keysを作成します。
$ 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]
注：実際のメールアドレスではなく、キーが使用されるホストのusername@fqdnを使用します。多くのマシンでこのロールアカウントを使用する場合、それぞれに独自のキーが必要です。ホストのFQDNを使用することにより、どのキーがどれであるかを知ることができます。このドキュメントでは、username@fqdnを$ keynameと呼びます
パスフレーズをどこかに安全に保存してください！
パスワードがないサブキーを作成します。
$ 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
このディレクトリをNewmasterに安全にエクスポートします。
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
Newmasterで、新しいgnupg configを受け取ります。
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
SecureHostに戻って、新しいメールアドレスを.blackbox/blackbox-admins.txtに追加します：
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
secring.gpgがゼロ長さのファイルであることを確認します。そうでない場合は、キーリングに秘密鍵を何らかの形で追加しました。やり直してください。
cd .blackbox
ls -l secring.gpg
最近の変更をコミットします：
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
新しいキーを使用して、暗号化されたすべてのファイルを再生します。
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
Newmasterで、キーをインポートしてファイルを復号化します。
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：「GPG：復号化が失敗した：秘密の鍵なし」を取得した場合、新しいキーを使用してBlackbox.yamlを再クリップするのを忘れました。
SecureHostでは、ファイルを安全に削除します。
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
また、作成した他の一時的なファイルを細断します。
誰かの鍵がすでに期限切れになっている場合、ブラックボックスは暗号化を停止します。このエラーが表示されます：
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
また、このコマンドを発行し、「期限切れ」を手動でレビューすることにより、期限切れになっているキーを検出することもできます。
gpg --homedir=.blackbox --list-keys
または...今日から1か月以内に期限切れになるUIDをリストします：（警告：これも有効期限のないキーをリストします）
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
キーを交換する方法は次のとおりです。
警告：このプロセスは、編集のプロセスにあった暗号化されていないファイルを消去します。他の場所にコピーして、完了したら変更を復元します。
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
上書きされないように一時的にコピーされたファイルは、 blackbox_edit_endコマンドでコピーして再クリックすることができます。
（この問題の解決策を見つけてくれた@chishakuに感謝します！）
git diffまたはgit logを介して実行する前に、ファイルのバージョンを復号化するようにgitに指示することができます。これを達成するために：
.gitattributesに以下を追加します。 *.gpg diff=blackbox
.git/configに以下を追加します。 [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
そして、 git log -p file.gpgのようなコマンドには、暗号化されたファイルの変更の素晴らしいログが表示されます。
gpg: filename: skipped: No public key通常、これはキーの名前ではない.blackbox/blackbox-admins.txtにアイテムがあることを意味します。無効なものが挿入されたもの（ユーザー名の代わりにファイル名のように）か、ユーザーが組織を離れ、キーがキーチェーンから削除されましたが、その名前はBlackbox-admins.txtファイルから削除されませんでした。
gpg: decryption failed: No secret key - 通常、新しいキーを使用してファイルを再クリップするのを忘れていました。
Error: can't re-encrypt because a key has expired. - ユーザーのキーの有効期限が切れており、これ以上暗号化するために使用できません。失効したキーのチップを交換してください。
参考までに、リポジトリは.blackboxの代わりにkeyrings/liveを使用できます。 「構成はどこに保存されていますか？」を参照してください。
ファイルがリポジトリからコピーされている場合、それらは引き続き復号化されて編集できます。明らかに編集、キーへの変更、およびリポジトリの外で行われた場合、そのようなものは失われます。また、コマンドは、ベースディレクトリから実行される場合にのみ機能する可能性が最も高いことに注意してください（つまり、親を.blackboxディレクトリまで）。
次のコマンドは、レポの外でテストされています。
blackbox_postdeployblackbox_edit_startblackbox_edit_end現在の実装では、ブラックボックスをリポジトリ全体のルートに/keyringsに保存します。これにより、ルートが異なる環境間に問題が発生します（つまり/開発中/releases/foo ）。これを回避するには、 export BLACKBOX_REPOBASE=/path/to/repo 、リポジトリ用の特定のベースを設定できます。
これはもともとGITのために書かれており、2フェーズのコミットをサポートします。このコミットでは、 commitローカルコミットであり、「プッシュ」は、システムが登録または登録されているときにバージョン制御サーバーに上流の変更を送信します。 blackbox_*コマンドを実行すると、現在の実装はすぐに（上流のSubversionサーバーに）ファイルをcommit 。
状況によっては、チームメンバーまたは自動化された役割は、GPG 2.xをシステムGPGバージョン1.xと一緒にインストールして、チームのGPGバージョンに追いつく必要があります。 Ubuntu 16では、バイナリGPG2をインストールするapt-get install gnupg2できます。このGPG2バイナリを使用する場合は、GPG = GPG2ですべてのBlackboxコマンドを実行します。
例えば：
GPG=gpg2 blackbox_postdeploy
質問、バグレポート、フィードバックを歓迎します！
開始するのに最適な場所は、Blackbox-Projectメーリングリストに参加してそこで尋ねることです。
バグはGithubでここで追跡されています。バグを自分で報告してください。
コードの送信は喜んで歓迎されます！コードはかなり読みやすいです。
コードを取得します：
git clone [email protected]:StackExchange/blackbox.git
変更をテストします：
make confidence
これは、多くのシステムテストを実行します。リポジトリを作成し、ファイルを暗号化し、ファイルを復号化します。これらのテストを実行して、行った変更が何も壊れていないことを確認できます。また、これらのテストを使用して、システムが新しいオペレーティングシステムで動作することを確認することもできます。
コードの変更を使用したテストを送信してください。
Blackboxを変更する最良の方法は、テスト駆動型開発を介してです。最初にtools/confidence.shにテストを追加します。このテストは失敗し、あなたがしようとしている変化の必要性を示しているはずです。次に、バグを修正するか、必要な機能を追加します。完了したら、すべてのテストに合格する必要がありmake confidence 。提出するPRには、コードと新しいテストを含める必要があります。このようにして、将来の変更が古い機能を壊さないことがわかっているため、システムが成長するにつれて信頼性テストが蓄積します。
注：現在、テストは「Git」を想定しており、Centos、Mac OS X、およびCygwinでのみテストされています。パッチを歓迎します！
Blackboxに似た何かを行う他のオープンソースパッケージを以下に示します。ブラックボックスよりも好きなら、それらを使用してください。
Git-Cryptには最高のGit統合があります。セットアップすると、ユーザーに対してほぼ透明になります。ただし、Gitでのみ機能します。
このコンテンツは、MITライセンスの下でリリースされます。 license.txtファイルを参照してください。
