blackbox
v1.20220610
Simpan rahasia dengan aman dalam repo VCS (yaitu git, mercurial, subversi atau perforasi). Perintah -perintah ini memudahkan Anda untuk merangkai file spesifik GNU Privacy Guard (GPG) dalam repo sehingga mereka "dienkripsi saat istirahat" di repositori Anda. Namun, skrip memudahkan untuk mendekripsi mereka ketika Anda perlu melihat atau mengeditnya, dan mendekripsi untuk digunakan dalam produksi. Awalnya ditulis untuk boneka, BlackBox sekarang bekerja dengan repositori git atau mercurial apa pun.
Peringatan: Tujuan dari proyek ini adalah untuk menjadi pembungkus sederhana di sekitar gpg sehingga Anda dan rekan kerja Anda tidak harus mengingat semua bendera yang tidak dapat dipahami dan membingungkan. Ini tidak dimaksudkan untuk menjadi sistem enkripsi canggih yang memecahkan semua masalah atau mendukung sejumlah besar file. Kasus penggunaan yang ideal adalah menyimpan rahasia dalam layanan yang aman seperti Conjur, AWS KMS, Azure Key Vault atau GCP KMS; Kemudian gunakan Blackbox untuk menyimpan kunci API yang diperlukan untuk mengakses sistem itu. Dengan begitu Anda mengenkripsi satu, file kecil. Permintaan-fitur untuk sesuatu yang lebih akan ditolak; Jangan mengharapkan atau bahkan meminta "fitur perusahaan". Jika ini mengecewakan Anda, harap pertimbangkan proyek yang bersaing seperti https://www.agwa.name/projects/git-crypt
Presentasi slide (tentang rilis yang lebih lama) ada di slideshare.
Bergabunglah dengan milis kami: https://groups.google.com/d/forum/blackbox-project
Misalkan Anda memiliki repositori VCS (yaitu repo git atau lincah) dan file -file tertentu berisi rahasia seperti kata sandi atau kunci pribadi SSL. Seringkali orang hanya menyimpan file seperti itu "dan berharap tidak ada yang menemukannya di repo". Itu tidak aman.
Dengan BlackBox, file -file tersebut disimpan dienkripsi menggunakan GPG. Akses ke repo VCS tanpa juga memiliki tombol GPG yang tepat membuatnya tidak berharga untuk memiliki file. Selama Anda menjaga kunci GPG Anda aman, Anda tidak perlu khawatir menyimpan repo VCS Anda di server yang tidak dipercaya. Heck, bahkan jika Anda mempercayai server Anda, sekarang Anda tidak perlu mempercayai orang -orang yang melakukan cadangan server itu, atau orang -orang yang menangani kaset cadangan!
Daripada satu frasa sandi GPG untuk semua file, setiap orang dengan akses memiliki kunci GPG sendiri dalam sistem. File apa pun dapat didekripsi oleh siapa pun dengan kunci GPG mereka. Dengan cara ini, jika satu orang meninggalkan perusahaan, Anda tidak perlu mengkomunikasikan kata sandi baru kepada semua orang dengan akses. Cukup nonaktifkan satu kunci yang seharusnya tidak lagi memiliki akses. Proses untuk melakukan ini semudah menjalankan 2 perintah (1 untuk menonaktifkan kunci mereka, 1 untuk memasukkan kembali semua file.)
Proses otomatis sering membutuhkan akses ke semua file yang didekripsi. Ini juga mudah. Misalnya, misalkan git digunakan untuk file boneka. Master membutuhkan akses ke versi yang didekripsi dari semua file. Cukup atur kunci GPG untuk master boneka (atau akun peran yang mendorong file baru ke master boneka) dan minta pengguna menjalankan blackbox_postdeploy setelah file apa pun diperbarui.
Jika Anda tidak memiliki kunci GPG, atur menggunakan instruksi seperti: Atur tombol GPG.
Sekarang Anda siap untuk pergi.
cd menjadi repositori Git, Mercurial, Subversion atau Perforce dan jalankan blackbox_initialize .
Jika suatu file akan dienkripsi, jalankan blackbox_register_new_file dan Anda selesai.
Tambahkan dan hapus tombol dengan blackbox_addadmin dan blackbox_removeadmin .
Untuk melihat dan/atau mengedit file, jalankan blackbox_edit ; Ini akan mendekripsi file dan terbuka dengan apa pun yang ditentukan oleh variabel lingkungan $ editor Anda.
Saat Anda menutup editor, file akan secara otomatis dienkripsi lagi dan file plaintext sementara akan dirobek.
Jika Anda perlu meninggalkan file didekripsi saat Anda memperbarui, Anda dapat menggunakan blackbox_edit_start untuk mendekripsi file dan blackbox_edit_end saat Anda ingin "memasukkannya kembali ke dalam kotak."
Jelas kami tidak ingin hal -hal rahasia seperti kunci pribadi SSL dan kata sandi bocor.
Tidak begitu jelas ketika kita menyimpan "rahasia" dalam repo VCS seperti git atau lincah, tiba -tiba kita kurang mampu berbagi kode kita dengan orang lain. Komunikasi antara subteam suatu organisasi terluka. Anda tidak dapat berkolaborasi juga. Entah Anda mendapati diri Anda mengirim email ke masing -masing file di sekitar (yuck!), Membuat repo khusus hanya dengan file yang dibutuhkan oleh kolaborator Anda (yuck !!), atau hanya memutuskan bahwa kolaborasi itu tidak sepadan dengan semua upaya itu (yuck !!!).
Kemampuan untuk bersikap terbuka dan transparan tentang kode kami, dengan pengecualian beberapa file tertentu, adalah kunci untuk jenis kolaborasi yang perlu dilakukan oleh DevOps dan praktisi TI modern.
make copy-install akan menyalin file bin ke $ prefix/bin, default adalah/usr/local (uninstall dengan make copy-uninstall ).make symlinks-install akan membuat symlink file bin menjadi $ prefix/bin, default adalah/usr/local (uninstall dengan make copy-uninstall ) (berguna saat melakukan pengembangan)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm ; Sekarang Anda dapat mendistribusikan RPM melalui metode lokal. (Membutuhkan FPM.)make packages-deb ; Sekarang Anda dapat mendistribusikan DEB melalui metode lokal. (Membutuhkan FPM.)antigen bundle StackExchange/blackbox ke .ZShrc Andazgenom load StackExchange/blackbox ke .ZShrc Anda di mana Anda memuat plugin Anda yang lain.nix-shell -p blackboxpkgin in scm-blackbox| Nama: | Keterangan: |
|---|---|
blackbox_edit <file> | Mendekripsi, jalankan $ editor, ingat ulang file |
blackbox_edit_start <file> | Mendekripsi file sehingga dapat diperbarui |
blackbox_edit_end <file> | Mengenkripsi file setelah blackbox_edit_start digunakan |
blackbox_cat <file> | Mendekripsi dan melihat konten file |
blackbox_view <file> | Seperti blackbox_cat tetapi pipa menjadi less atau $ pager |
blackbox_diff | File didekripsi berbeda terhadap versi crypted aslinya |
blackbox_initialize | Aktifkan BlackBox untuk repo git atau HG |
blackbox_register_new_file <file> | Mengenkripsi file untuk pertama kalinya |
blackbox_deregister_file <file> | Hapus file dari Blackbox |
blackbox_list_files | Buat daftar file yang dikelola oleh Blackbox |
blackbox_list_admins | Daftar Admins saat ini diizinkan untuk Blackbox |
blackbox_decrypt_file <file> | Mendekripsi file |
blackbox_decrypt_all_files | Mendekripsi semua file yang dikelola (interaktif) |
blackbox_postdeploy | Mendekripsi semua file yang dikelola (batch) |
blackbox_addadmin <gpg-key> | Tambahkan seseorang ke daftar orang yang dapat mengenkripsi/mendekripsi rahasia |
blackbox_removeadmin <gpg-key> | Hapus seseorang dari daftar orang yang dapat mengenkripsi/mendekripsi rahasia |
blackbox_shred_all_files | Hapus file yang didekripsi dengan aman |
blackbox_update_all_files | Dekripsi kemudian menelan ulang semua file. Berguna setelah kunci diubah |
blackbox_whatsnew <file> | Tunjukkan apa yang telah berubah dalam komitmen terakhir untuk file yang diberikan |
Blackbox secara otomatis menentukan VC mana yang Anda gunakan dan melakukan hal yang benar. Ini memiliki arsitektur plug-in untuk memudahkan untuk bekerja dengan sistem lain. Ini telah diuji untuk bekerja dengan banyak sistem operasi.
git - githg - Mercurialsvn - Subversion (terima kasih, Ben Drasin!)p4 - Perforce.blackbox masih utuh Untuk menambah atau memperbaiki dukungan untuk sistem VCS, cari kode di akhir bin/_blackbox_common.sh
Untuk menambah atau memperbaiki dukungan untuk sistem operasi baru, cari pernyataan kasus di bin/_blackbox_common.sh dan bin/_stack_lib.sh dan mungkin tools/confidence_test.sh
Blackbox dapat digunakan dengan Cygwin, Mingw atau WSL2.
Blackbox mengasumsikan bahwa blackbox-admins.txt dan blackbox-files.txt akan memiliki ujung garis LF. Pengguna Windows harus berhati -hati untuk mengonfigurasi GIT atau sistem lain agar tidak mengonversi atau "memperbaiki" file tersebut.
Jika Anda menggunakan git, tambahkan baris berikut ke file .gitattributes Anda:
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
Versi terbaru dari blackbox_initialize akan membuat file .gitattributes di direktori $BLACKBOXDATA (biasanya .blackbox ) untuk Anda.
Dukungan Cygwin membutuhkan paket berikut:
Operasi Normal:
Pengembangan (jika Anda akan menambahkan kode dan ingin menjalankan tes kepercayaan)
Mingw (dilengkapi dengan git for windows) dukungan membutuhkan yang berikut:
Operasi Normal:
MINTTY , bukan konsol Windows. Anda akan mengeksekusi BlackBox dari Git Bash Prompt.download.bat Setelah selesai run install.bat kemudian tambahkan jalur untuk alat -alat itu ke jalur Anda (mis: PATH=%PATH%;c:GnuWin32bin )Perkembangan:
make test )Jika Anda mendapatkan kesalahan berikut di WSL2, Anda dapat mencoba mengatur lingkungan Anda dengan instruksi berikut (diuji dengan Ubuntu 22.04 di WSL2):
~/.gnupg/gpg-agent.conf di wsl dan tambahkan baris berikut: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeGPG memiliki banyak cara berbeda untuk mengenkripsi file. Blackbox menggunakan mode yang memungkinkan Anda menentukan daftar kunci yang dapat mendekripsi pesan.
Jika Anda memiliki 5 orang ("admin") yang seharusnya dapat mengakses rahasia, masing -masing membuat kunci GPG dan menambahkan kunci publik mereka ke gantungan kunci. Perintah GPG yang digunakan untuk mengenkripsi file mencantumkan semua 5 nama kunci, dan oleh karena itu setiap 1 kunci dapat mendekripsi file.
Untuk menghapus akses seseorang, hapus nama kunci admin (yaitu alamat email) dari daftar admin dan encrypt ulang semua file. Mereka masih dapat membaca file .gpg (dengan asumsi mereka memiliki akses ke repositori) tetapi mereka tidak dapat mendekripsi lagi.
Bagaimana jika mereka menyimpan salinan repo lama sebelum Anda menghapus akses? Ya, mereka dapat mendekripsi versi lama dari file tersebut. Inilah sebabnya ketika admin meninggalkan tim, Anda harus mengubah semua kata sandi Anda, sertifikat SSL, dan sebagainya. Anda seharusnya melakukan itu sebelum Blackbox, bukan?
Mengapa Anda tidak menggunakan kunci simetris? Dengan kata lain, mengapa mengacaukan semua hal kunci GPG ini dan sebaliknya mengapa kita tidak mengenkripsi semua file dengan satu frasa sandi tunggal. Ya, GPG mendukung itu, tetapi kemudian kami mengelola kata sandi bersama, yang penuh dengan masalah. Jika seseorang "meninggalkan tim", kami harus berkomunikasi dengan semua orang sebagai kata sandi baru. Sekarang kita hanya perlu menghapus kunci mereka. Ini berskala lebih baik.
Bagaimana proses dekripsi otomatis tanpa meminta kata sandi? GPG membutuhkan frasa sandi pada kunci pribadi. Namun, itu memungkinkan penciptaan subkey yang tidak memiliki frasa sandi. Untuk proses otomatis, buat subkey yang hanya disimpan di mesin yang perlu mendekripsi file. Misalnya, di Stack Exchange, ketika sistem Integrasi Berkelanjutan (CI) kami mendorong perubahan kode ke master boneka kami, mereka menjalankan blackbox_postdeploy untuk mendekripsi semua file. Pengguna yang menjalankan kode ini memiliki subkey yang tidak memerlukan frasa sandi. Karena kami memiliki banyak tuan, masing -masing memiliki kunci sendiri. Dan, ya, ini berarti tuan boneka kita harus sangat aman. Namun, mereka sudah aman karena, seperti, bung ... jika Anda dapat membobol master boneka seseorang, Anda memiliki jaringan mereka.
Jika Anda menggunakan boneka, mengapa Anda tidak menggunakan Hiera-E-E-eyaml? Ada 4 alasan:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a atau hg commit Tunggu ... bisa lebih mudah dari itu! Jalankan blackbox_edit FILENAME , dan itu akan mendekripsi file dalam file temp dan hubungi $EDITOR di atasnya, encrypting lagi setelah editor ditutup.
Ansible Vault menyediakan fungsionalitas untuk mengenkripsi seluruh file dan string yang disimpan dalam file; Namun, melacak kata sandi yang diperlukan untuk dekripsi tidak ditangani oleh modul ini.
Sebaliknya seseorang harus menentukan file kata sandi saat menjalankan buku pedoman.
Contoh ansible untuk file kata sandi: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
Atau, orang dapat menentukan ini di variabel lingkungan ANSIBLE_VAULT_PASSWORD_FILE .
Seluruh file, seperti sertifikat SSL dan kunci pribadi, diperlakukan seperti file biasa. Anda mendekripsi mereka setiap kali Anda mendorong rilis baru ke master boneka.
Contoh boneka untuk file terenkripsi: 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",
}
String kecil, seperti kata sandi dan kunci API, disimpan dalam file Hiera Yaml, yang Anda enkripsi dengan blackbox_register_new_file . Misalnya, kami menggunakan file yang disebut blackbox.yaml . Anda dapat mengaksesnya menggunakan fungsi Hiera ().
Pengaturan: Konfigurasikan hiera.yaml dengan menambahkan "BlackBox" ke hierarki pencarian:
:hierarchy:
- ...
- blackbox
- ...
Di blackbox.yaml tentukan:
---
module::test_password: "my secret password"
Dalam kode boneka Anda, akses kata sandi seperti halnya data Hiera apa pun:
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
Variabel $the_password akan berisi "Kata Sandi Rahasia Saya" dan dapat digunakan di mana saja string digunakan.
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
Beberapa nama file dapat ditentukan pada baris perintah:
Contoh 1: Daftar 2 File:
blackbox_register_new_file file1.txt file2.txt
Contoh 2: Daftarkan semua file dalam $DIR :
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
Ini terjadi cukup jarang, tetapi kami sudah membahasnya:
blackbox_deregister_file path/to/file.name.key
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
.blackbox/blackbox-admins.txt adalah file yang mencantumkan pengguna mana yang dapat mendekripsi file. (Lebih pedantis, ini adalah daftar nama kunci GNUPG yang dienkripsi file.)
Untuk bergabung dengan daftar orang yang dapat mengedit file membutuhkan tiga langkah; Anda membuat kunci GPG dan menambahkannya ke cincin kunci. Kemudian, seseorang yang sudah memiliki akses menambahkan Anda ke sistem. Terakhir, Anda harus menguji akses Anda.
Jika Anda belum memiliki kunci GPG, inilah cara menghasilkan satu:
gpg --gen-key
Peringatan: Versi baru GPG menghasilkan kunci yang tidak dipahami oleh versi lama GPG. Jika Anda menghasilkan kunci dengan versi GPG baru, ini akan menyebabkan masalah bagi pengguna GPG versi lama. Oleh karena itu disarankan agar Anda memastikan bahwa setiap orang yang menggunakan BlackBox memiliki versi GPG yang sama persis, atau menghasilkan tombol GPG menggunakan versi GPG setua GPG versi tertua yang digunakan oleh semua orang menggunakan BlackBox.
Pilih default untuk pengaturan enkripsi, 0 kedaluwarsa. Pilih frasa sandi yang sangat bagus. Simpan cadangan kunci pribadi di suatu tempat aman. Misalnya, simpan salinan cadangan pada drive USB yang terkunci di aman. Atau, setidaknya taruh di mesin yang aman dengan sedikit atau tanpa akses internet, enkripsi penuh, dll. Majikan Anda mungkin memiliki aturan tentang cara menyimpan barang-barang seperti itu.
FYI: Jika menghasilkan kunci lambat, ini biasanya karena sistem tidak menghasilkan cukup entropi. Kiat: Buka jendela lain di mesin itu dan jalankan perintah ini: ls -R /
Sekarang Anda memiliki kunci GPG, tambahkan diri Anda sebagai admin:
blackbox_addadmin KEYNAME
... Di mana "Keyname" adalah alamat email yang tercantum dalam tombol GPG yang Anda buat sebelumnya. Misalnya:
blackbox_addadmin [email protected]
Ketika perintah berhasil selesai, instruksi tentang cara melakukan perubahan ini akan menjadi output. Jalankan perintah seperti yang diberikan untuk melakukan perubahan. Ini akan terlihat seperti ini:
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
Kemudian dorong ke repo:
git push
or
ht push
(or whatever is appropriate)
Catatan: Membuat akun peran? Jika Anda menambahkan pubring.gpg dari akun peran, Anda dapat menentukan direktori di mana file pubring.gpg dapat ditemukan sebagai parameter ke-2: blackbox_addadmin [email protected] /path/to/the/dir
Tanyakan kepada seseorang yang sudah memiliki akses untuk memasukkan kembali file data. Ini memberi Anda akses. Mereka hanya mendekripsi dan menerima kembali data tanpa membuat perubahan apa pun.
Pre-check: Verifikasi tombol baru terlihat bagus.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
Misalnya, periksa nama kunci (alamat email) untuk memastikan itu sesuai dengan standar perusahaan.
Impor gantungan kunci ke gantungan kunci pribadi Anda dan reencrypt:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
Dorong file yang dienkripsi ulang:
git commit -a
git push
or
hg commit
hg push
Pastikan Anda dapat mendekripsi file. (Saran: Simpan file dummy di VC hanya untuk orang baru untuk berlatih.)
Cukup jalankan blackbox_removeadmin dengan keyname mereka kemudian terenkripsi ulang:
Contoh:
blackbox_removeadmin [email protected]
blackbox_update_all_files
Ketika perintah selesai, Anda akan diberikan pengingat untuk memeriksa perubahan dan mendorongnya.
Perhatikan bahwa kunci mereka masih ada di cincin kunci, tetapi mereka tidak akan digunakan. Jika Anda ingin membersihkan keyring, gunakan perintah GPG normal dan periksa file.
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
Cincin kunci hanya memiliki kunci publik. Tidak ada kunci rahasia untuk dihapus.
Ingatlah bahwa orang ini memang memiliki akses ke semua rahasia pada satu waktu. Mereka bisa membuat salinannya. Oleh karena itu, untuk sepenuhnya aman, Anda harus mengubah semua kata sandi, menghasilkan kunci SSL baru, dan seterusnya seperti ketika siapa pun yang memiliki akses istimewa meninggalkan sebuah organisasi.
Memvalidasi kepercayaan kunci adalah tugas yang tidak dapat diselesaikan oleh Blackbox; Ini adalah topik yang sepenuhnya eksternal yang harus ditangani secara manual (cara yang sama seperti menghasilkan/mengelola kunci Anda adalah, misalnya) atau dengan mekanisme khusus (perusahaan CA dengan alur kerja yang sesuai misalnya). Selain manfaat "umum" dari web kepercayaan (lihat di sini atau di sini misalnya), itu mencegah beberapa kesalahan juga.
Secara historis Blackbox menggunakan dan menegakkan model "kepercayaan setiap kunci" tetapi ini telah berubah! Sekarang keputusan apakah dan bagaimana menggunakan model PGP/GPG Trust diserahkan kepada pengguna berdasarkan konfigurasi (atau oleh default PGP/GPG).
Saat memperbarui Blackbox, orang mungkin mengalami masalah fungsional jika mereka belum berurusan dengan kemampuan dapat dipercaya dari kunci yang mereka gunakan. Ini adalah waktu yang tepat untuk melakukannya dan membangun web kepercayaan Anda sekarang!
Jika Anda memiliki alur kerja eksternal di tempat yang memastikan integritas kunci yang digunakan Blackbox, Anda mungkin ingin menonaktifkan model PGP/GPG Trust dan mengandalkan alur kerja ini.
Ini dapat dicapai dengan mendeklarasikan "model kepercayaan selalu", baik dengan melewati parameter baris perintah --trust-model=always ke biner pgp/gpg Anda saat menggunakan blackbox (dengan mendefinisikan alias atau menggunakan variabel lingkungan (misalnya GPG="gpg2 --trust-model=always" ) atau kombinasi keduanya) atau dengan mengatur trust-model always di gpg.conf Anda (perhatikan bahwa ini menonaktifkan web kepercayaan di mana-mana, bukan hanya untuk Blackbox).
PERINGATAN: Sangat dirugikan untuk tidak menggunakan validasi kunci sama sekali! Ini membuka berbagai cara untuk memotong kerahasiaan rahasia terenkripsi Anda!
Blackbox menyimpan data konfigurasinya di subdirektori .blackbox . Repo yang lebih tua menggunakan keyrings/live . Untuk kompatibilitas ke belakang akan berhasil.
Semua dokumentasi mengacu pada .blackbox .
Anda dapat mengonversi repo lama hanya dengan mengganti nama direktori:
mv keyrings/live .blackbox
rmdir keyrings
Tidak ada alasan teknis untuk mengonversi repo lama kecuali bahwa itu kurang membingungkan bagi pengguna.
Perubahan ini dilakukan dalam komit 60e782a0, rilis v1.20180615.
Detailnya:
$BLACKBOXDATA . Jika variabel lingkungan ini ditetapkan, ini adalah direktori yang akan digunakan. Jika mencantumkan direktori yang tidak ada, Blackbox akan mencetak kesalahan dan keluar.$BLACKBOXDATA tidak disetel: (yang merupakan kasus penggunaan khas)keyrings/live dan menggunakannya jika ada..blackbox default akan digunakan. Jika .blackbox tidak ada, BlackBox akan mencetak kesalahan dan keluar.Ringkasan:
Untuk menambahkan "BlackBox" ke git atau repo lincah, Anda harus melakukan hal berikut:
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
Anda ingin menyertakan direktori "bin" Blackbox di jalur Anda:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
Jika Anda menggunakan antigen, menambahkan antigen bundle StackExchange/blackbox ke .ZShrc Anda akan mengunduh repositori ini dan menambahkannya ke jalur $ Anda.
Ikuti instruksi untuk "Cara mengindoktrinasi pengguna baru ke dalam sistem?". Hanya langkah 1.
Setelah selesai, adalah ide yang baik untuk menguji sistem dengan memastikan file dapat ditambahkan ke sistem (lihat "Cara mendaftarkan file baru ke dalam sistem?"), Dan pengguna yang berbeda dapat mendekripsi file.
Buat file baru dan daftarkan:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
Mendekripsi:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
Mengenkripsi ulang:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
Anda hanya akan melihat foo.txt.gpg sebagai foo.txt harus hilang.
Langkah selanjutnya adalah melakukan foo.txt.gpg dan pastikan pengguna lain dapat memeriksa, melihat, dan mengubah konten file. Itu tersisa sebagai latihan untuk pembaca. Jika Anda merasa ingin mengambil risiko, jangan melakukan foo.txt.gpg dan hapus saja.
yaitu ini adalah bagaimana master boneka dapat memiliki akses ke data yang tidak terenkripsi.
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
Pengguna otomatis ("akun peran") adalah salah satu yang harus dapat mendekripsi tanpa frasa sandi. Secara umum Anda akan ingin melakukan ini untuk pengguna yang menarik file dari repo ke master. Ini mungkin otomatis dengan Jenkins CI atau sistem CI lainnya.
Kunci GPG harus memiliki frasa sandi. Namun, frasa sandi adalah opsional pada subkey. Oleh karena itu, kami akan membuat kunci dengan frasa sandi kemudian membuat subkey tanpa frasa sandi. Karena subkey sangat kuat, itu harus dibuat pada mesin yang sangat aman.
Ada tangkapan lain. Akun Peran mungkin tidak dapat memeriksa file ke dalam git/Mercurial. Mungkin hanya memiliki akses baca saja ke repo. Itu kebijakan keamanan yang bagus. Ini berarti bahwa akun peran tidak dapat digunakan untuk mengunggah bit publik subkey ke dalam repo.
Karena itu, kami akan membuat kunci/subkey pada mesin yang aman seperti Anda. Dari sana kita dapat melakukan bagian publik ke dalam repo. Juga dari akun ini kami akan mengekspor bagian -bagian yang dibutuhkan akun peran, menyalinnya ke tempat akun peran dapat mengaksesnya, dan mengimpornya sebagai akun peran.
ProTip: Jika diminta untuk menghasilkan entropi, pertimbangkan untuk menjalankan ini di mesin yang sama di jendela lain: sudo dd if=/dev/sda of=/dev/null
Untuk sisa dokumen ini, Anda harus membuat substitusi berikut:
Catatan: Ini harus lebih otomatis/ditulis. Patch Selamat Datang.
Di SecureHost, buat kunci master boneka:
$ 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]
Catatan: Daripada alamat email nyata, gunakan nama pengguna@fqdn dari host, kunci akan digunakan. Jika Anda menggunakan akun peran ini pada banyak mesin, masing -masing harus memiliki kunci sendiri. Dengan menggunakan FQDN host, Anda akan dapat mengetahui kunci mana yang mana. Di dokumen ini, kami akan merujuk ke username@fqdn sebagai $ keyname
Simpan frasa sandi di suatu tempat yang aman!
Buat sub-key yang tidak memiliki kata sandi:
$ 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
Sekarang dengan aman mengekspor direktori ini ke Newmaster:
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
Di Newmaster, terima konfigurasi GNUPG baru:
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
Kembali ke SecureHost, tambahkan alamat email baru ke .BlackBox/Blackbox-admins.txt:
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
Pastikan bahwa Secring.gpg adalah file panjang nol. Jika tidak, Anda entah bagaimana menambahkan kunci pribadi ke keyring. Mulai dari awal.
cd .blackbox
ls -l secring.gpg
Melakukan perubahan terbaru:
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
Regenerasi semua file terenkripsi dengan kunci baru:
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
Di Newmaster, impor kunci dan dekripsi file:
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: Jika Anda mendapatkan "GPG: Dekripsi Gagal: No Secret Key" maka Anda lupa untuk memasukkan kembali BlackBox.YAML dengan kunci baru.
Di SecureHost, hapus file Anda dengan aman:
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
Juga merobek -robek file sementara lainnya yang mungkin telah Anda buat.
Jika kunci seseorang sudah kedaluwarsa, Blackbox akan berhenti mengenkripsi. Anda melihat kesalahan ini:
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
Anda juga dapat mendeteksi kunci yang akan kedaluwarsa dengan mengeluarkan perintah ini dan secara manual meninjau "kedaluwarsa:" Tanggal:
gpg --homedir=.blackbox --list-keys
atau ... daftar uids yang akan kedaluwarsa dalam 1 bulan dari hari ini: (Peringatan: Ini juga mencantumkan kunci tanpa tanggal kedaluwarsa)
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
Inilah cara mengganti kunci:
PERINGATAN: Proses ini akan menghapus file yang tidak terenkripsi yang Anda lakukan dalam proses pengeditan. Salin di tempat lain dan kembalikan perubahan saat selesai.
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
File apa pun yang sementara disalin pada langkah pertama agar tidak ditimpa sekarang dapat disalin kembali dan dienkripsi ulang dengan perintah blackbox_edit_end .
(Terima kasih kepada @Chishaku untuk menemukan solusi untuk masalah ini!)
Dimungkinkan untuk memberi tahu Git untuk mendekripsi versi file sebelum menjalankannya melalui git diff atau git log . Untuk mencapai hal ini, lakukanlah:
.gitattributes di bagian atas repositori git: *.gpg diff=blackbox
.git/config : [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
Dan sekarang perintah seperti git log -p file.gpg akan menampilkan log yang bagus dari perubahan dalam file terenkripsi.
gpg: filename: skipped: No public key -biasanya ini berarti ada item di .blackbox/blackbox-admins.txt itu bukan nama kunci. Entah sesuatu yang tidak valid dimasukkan (seperti nama file, bukan nama pengguna) atau pengguna telah meninggalkan organisasi dan kunci mereka dihapus dari gantungan kunci, tetapi nama mereka tidak dihapus dari file blackbox-admins.txt.
gpg: decryption failed: No secret key -biasanya berarti Anda lupa untuk memasukkan kembali file tersebut dengan kunci baru.
Error: can't re-encrypt because a key has expired. - Kunci pengguna telah kedaluwarsa dan tidak dapat digunakan untuk mengenkripsi lagi. Ikuti Tip Kunci Ganti Kadaluwarsa.
FYI: Repo Anda dapat menggunakan keyrings/live bukan .blackbox . Lihat "Di mana konfigurasinya disimpan?"
Jika file disalin keluar dari repo, mereka masih dapat didekripsi dan diedit. Jelas suntingan, perubahan pada kunci, dan semacamnya akan hilang jika dibuat di luar repo. Perhatikan juga bahwa perintah paling mungkin hanya berfungsi jika dijalankan dari direktori dasar (yaitu orang tua ke direktori .BlackBox).
Perintah berikut telah diuji di luar repo:
blackbox_postdeployblackbox_edit_startblackbox_edit_end Implementasi saat ini akan menyimpan BlackBox di /keyrings pada akar seluruh repo. Ini akan menciptakan masalah antara lingkungan yang memiliki akar yang berbeda (yaitu memeriksa / pada pengembangan vs /releases/foo dalam produksi). Untuk menyiasati ini, Anda dapat export BLACKBOX_REPOBASE=/path/to/repo dan atur basis tertentu untuk repo Anda.
Ini awalnya ditulis untuk GIT dan mendukung komit dua fase, di mana commit adalah komit lokal dan "dorong" mengirimkan perubahan ke hulu ke server kontrol versi ketika sesuatu terdaftar atau dideregister dengan sistem. Implementasi saat ini akan segera commit file (ke server Subversion hulu) saat Anda menjalankan perintah blackbox_* .
Dalam beberapa situasi, anggota tim atau peran otomatis perlu menginstal GPG 2.x di samping sistem GPG versi 1.x untuk mengejar ketinggalan dengan versi GPG tim. Pada Ubuntu 16, Anda apt-get install gnupg2 yang menginstal GPG2 biner. Jika Anda ingin menggunakan biner GPG2 ini, jalankan setiap perintah BlackBox dengan GPG = GPG2.
Misalnya:
GPG=gpg2 blackbox_postdeploy
Kami menyambut pertanyaan, laporan bug, dan umpan balik!
Tempat terbaik untuk memulai adalah bergabung dengan milis Blackbox-Project dan bertanya di sana.
Bug dilacak di sini di GitHub. Silakan melaporkan bug sendiri.
Pengajuan kode disambut dengan senang hati! Kode ini cukup mudah dibaca.
Dapatkan kodenya:
git clone [email protected]:StackExchange/blackbox.git
Uji perubahan Anda:
make confidence
Ini berjalan melalui sejumlah tes sistem. Ini membuat repo, mengenkripsi file, mendekripsi file, dan sebagainya. Anda dapat menjalankan tes ini untuk memverifikasi bahwa perubahan yang Anda buat tidak merusak apa pun. Anda juga dapat menggunakan tes ini untuk memverifikasi bahwa sistem bekerja dengan sistem operasi baru.
Harap kirim tes dengan perubahan kode:
Cara terbaik untuk mengubah Blackbox adalah melalui pengembangan yang didorong oleh tes. Pertama, tambahkan tes ke tools/confidence.sh Tes ini harus gagal, dan menunjukkan perlunya perubahan yang akan Anda lakukan. Kemudian perbaiki bug atau tambahkan fitur yang Anda inginkan. Setelah selesai, make confidence harus lulus semua tes. PR yang Anda kirim harus menyertakan kode Anda serta tes baru. Dengan cara ini tes kepercayaan menumpuk seiring dengan tumbuhnya sistem karena kita tahu perubahan di masa depan tidak merusak fitur lama.
Catatan: Tes saat ini menganggap "git" dan telah diuji hanya pada Centos, Mac OS X, dan Cygwin. Patch Selamat Datang!
Berikut adalah paket sumber terbuka lainnya yang melakukan sesuatu yang mirip dengan Blackbox. Jika Anda lebih suka mereka daripada Blackbox, silakan gunakan.
Git-Crypt memiliki integrasi git terbaik. Setelah mengaturnya hampir transparan bagi pengguna. Namun itu hanya bekerja dengan git.
Konten ini dirilis di bawah lisensi MIT. Lihat file lisensi.txt.
