blackbox
v1.20220610
VCS Repo (예 : Git, Mercurial, Pubversion 또는 Perforce)에 비밀을 안전하게 보관하십시오. 이 명령을 사용하면 GNU 개인 정보 보호 가드 (GPG)가 리포지토리에서 특정 파일을 암호화하여 저장소에서 "REST에서 암호화"할 수 있습니다. 그러나 스크립트를 사용하면 스크립트를 보거나 편집해야 할 때 쉽게 해독 할 수 있으며 프로덕션에 사용하기 위해 해독 할 수 있습니다. Puppet을 위해 원래 작성된 Blackbox는 이제 모든 git 또는 mercurial Repository와 함께 작동합니다.
경고 :이 프로젝트의 목표는 gpg 주변의 간단한 포장지가되므로 귀하와 귀하의 동료들은 그 모든 흠 잡을 수없고 혼란스러운 깃발을 기억할 필요가 없습니다. 모든 문제를 해결하거나 많은 파일을 지원하는 정교한 암호화 시스템이 아닙니다 . 이상적인 사용 사례는 CONHUR, AWS KMS, AZURE KEY VAULT 또는 GCP KMS와 같은 안전한 서비스에서 비밀을 유지하는 것입니다. 그런 다음 해당 시스템에 액세스하는 데 필요한 API 키를 안전하게 저장하기 위해 Blackbox를 사용하십시오. 그렇게하면 하나의 작은 파일을 암호화하고 있습니다. 더 많은 것을위한 특징 요청은 거부 될 것이다. "엔터프라이즈 기능"을 기대하거나 요청하지 마십시오. 이것이 실망 스럽으면 https://www.agwa.name/projects/git-crypt와 같은 경쟁 프로젝트를 고려하십시오.
슬라이드 프레젠테이션 (이전 릴리스 정보)은 SlideShare에 있습니다.
메일 링리스트에 가입하십시오 : https://groups.google.com/d/forum/blackbox-project에 가입하십시오
VCS 저장소 (예 : GIT 또는 Mercurial Repo)가 있다고 가정하고 특정 파일에는 암호 또는 SSL 개인 키와 같은 비밀이 포함되어 있습니다. 종종 사람들은 그러한 파일을 저장하고 "아무도 리포에서 그들을 찾지 않기를 바랍니다". 안전하지 않습니다.
Blackbox를 사용하면 해당 파일은 GPG를 사용하여 암호화 된 저장됩니다. 올바른 GPG 키도 갖지 않고 VCS Repo에 액세스하면 파일을 갖는 것이 가치가 없습니다. GPG 키를 안전하게 보관하는 한 VCS Repo를 신뢰할 수없는 서버에 저장하는 것에 대해 걱정할 필요가 없습니다. 서버를 신뢰하더라도 이제 서버의 백업을하는 사람들이나 백업 테이프를 처리하는 사람들을 신뢰할 필요가 없습니다!
모든 파일에 대해 하나의 GPG 암호를 사용하는 대신, 액세스가있는 각 사람은 시스템에 고유 한 GPG 키가 있습니다. 모든 파일은 GPG 키를 가진 사람이 누구나 해독 할 수 있습니다. 이런 식으로 한 사람이 회사를 떠나면 액세스 권한이있는 모든 사람에게 새 비밀번호를 전달할 필요가 없습니다. 더 이상 액세스 할 수없는 하나의 키를 비활성화합니다. 이 작업을 수행하는 프로세스는 2 명령을 실행하는 것만 큼 쉽습니다 (1은 키를 비활성화하고 1은 모든 파일을 다시 밀어 넣는 데 사용됩니다.)
자동화 된 프로세스는 종종 해독 된 모든 파일에 액세스해야합니다. 이것도 쉽습니다. 예를 들어, git이 꼭두각시 파일에 사용되고 있다고 가정합니다. 마스터는 모든 파일의 해독 된 버전에 대한 액세스가 필요합니다. 꼭두각시 마스터 (또는 새 파일을 꼭두각시 마스터에게 푸시하는 역할 계정)에 대한 GPG 키를 설정하고 파일이 업데이트 된 후에 사용자가 blackbox_postdeploy 실행하도록합니다.
GPG 키가없는 경우 : GPG 키 설정과 같은 지침을 사용하여 설정하십시오.
이제 갈 준비가되었습니다.
cd , git, mercurial, subversion 또는 perforce 저장소에 CD를 넣고 blackbox_initialize 실행하십시오.
파일을 암호화하려면 blackbox_register_new_file 실행하면 완료됩니다.
blackbox_addadmin 및 blackbox_removeadmin 으로 키를 추가하고 제거하십시오.
파일을보고/또는 편집하려면 blackbox_edit 실행하십시오. 이렇게하면 파일을 해독하고 $ 편집기 환경 변수로 지정된 내용으로 열립니다.
편집기를 닫으면 파일이 자동으로 다시 암호화되고 임시 일반 텍스트 파일이 파쇄됩니다.
업데이트하는 동안 파일을 암호 해독 해야하는 경우 blackbox_edit_start 파일과 blackbox_edit_end 해독 할 수 있습니다.
분명히 우리는 SSL 개인 키와 비밀번호와 같은 비밀스러운 것들이 유출되기를 원하지 않습니다.
우리가 Git 또는 Mercurial과 같은 VCS Repo에 "비밀"을 저장할 때, 갑자기 우리는 다른 사람들과 코드를 공유 할 수 없습니다. 조직의 하위 팀 간의 커뮤니케이션은 상처를받습니다. 당신도 협력 할 수 없습니다. 당신은 자신이 주변에 개별 파일을 이메일로 보내거나 (Yuck!), 공동 작업자 (Yuck !!)가 필요한 파일만으로 특별한 리포를 만들거나 협업이 모든 노력의 가치가 없다고 결정합니다 (Yuck !!!).
몇 가지 특정 파일을 제외하고 우리 코드에 대해 개방적이고 투명 할 수있는 능력은 DevOps와 최신 IT 실무자가해야 할 협업의 종류의 핵심입니다.
make copy-install 빈 파일을 $ prefix/bin에 복사합니다. 기본값은/usr/local ( make copy-uninstall 과 함께 제거)입니다.make symlinks-install Bin 파일의 Symlinks를 $ 접두사/빈으로, 기본값은/usr/local ( 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, run $ editor, 파일을 다시 암호화하십시오 |
blackbox_edit_start <file> | 파일을 해독하여 업데이트 할 수 있습니다 |
blackbox_edit_end <file> | Blackbox_edit_start가 사용 된 후 파일을 암호화합니다 |
blackbox_cat <file> | 파일의 내용을 해독하고 봅니다 |
blackbox_view <file> | BlackBox_Cat과 마찬가지로 파이프가 less 거나 $ 호출기입니다 |
blackbox_diff | 원래 암호화 버전에 대해 해독 된 파일을 차단합니다 |
blackbox_initialize | GIT 또는 HG Repo 용 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 머큐리리svn 전복 (감사합니다, Ben Drasin!)p4 천공.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 for Windows와 함께 제공) 지원은 다음이 필요합니다.
정상 작동 :
MINTTY 선택하십시오. Git Bash 프롬프트에서 Blackbox를 실행할 것입니다.PATH=%PATH%;c:GnuWin32bin download.bat install.bat개발:
make test 실행하기 위해 추가 패키지가 필요한지 알려주십시오)WSL2에서 다음 오류가 발생하면 다음 지침으로 환경을 설정할 수 있습니다 (WSL2에서 Ubuntu 22.04로 테스트).
~/.gnupg/gpg-agent.conf 파일을 편집하고 다음 줄을 추가하십시오 : 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 CERT 등을 변경해야합니다. 블랙 박스 전에 그렇게 했어야 했어요?
대칭 키를 사용하지 않는 이유는 무엇입니까? 다시 말해, 왜이 모든 GPG 키 제품을 엉망으로 만들고 대신 단일 암호로 모든 파일을 암호화하지 않는 이유는 무엇입니까? 예, GPG는이를 지원하지만 공유 비밀번호를 관리하고 있으며 문제가 발생합니다. 누군가가 "팀을 떠나"한다면 우리는 모든 사람에게 새로운 암호를 통신해야합니다. 이제 우리는 그들의 키를 제거해야합니다. 이것은 더 잘 확장됩니다.
자동화 된 프로세스는 비밀번호를 요구하지 않고 해독하는 방법은 무엇입니까? GPG는 개인 키에 암호를 필요로합니다. 그러나 암호가없는 하위 키를 생성 할 수 있습니다. 자동화 된 프로세스의 경우 파일을 해독 해야하는 시스템에만 저장된 하위 키를 만듭니다. 예를 들어, Stack Exchange에서 CI (Continuous Integration) 시스템이 코드 변경을 꼭두각시 마스터로 푸시하면 blackbox_postdeploy 실행하여 모든 파일을 해독합니다. 이 코드를 실행하는 사용자에게는 암호가 필요하지 않은 서브 키가 있습니다. 우리는 많은 마스터가 있기 때문에 각각 고유 한 열쇠가 있습니다. 그리고 그렇습니다. 이것은 우리의 꼭두각시 마스터가 매우 안전해야한다는 것을 의미합니다. 그러나 그들은 이미 안전했습니다.
꼭두각시를 사용하는 경우 왜 Hiera-Eyaml을 사용하지 않았습니까? 4 가지 이유가 있습니다.
eval $(gpg-agent --daemon) 를 시작하십시오.blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a 또는 hg commit 잠깐만 ... 그보다 훨씬 쉬울 수 있습니다! blackbox_edit FILENAME 실행하면 Temp 파일로 파일을 해독하고 편집기가 닫힌 후 다시 암호화하여 $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 및 개인 키와 같은 전체 파일은 일반 파일처럼 취급됩니다. 새로운 릴리스를 꼭두각시 마스터에게 밀어 넣을 때마다 해독합니다.
암호화 된 파일의 꼭두각시 예 : 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 키와 같은 작은 문자열은 Hiera Yaml 파일에 저장되며 blackbox_register_new_file 로 암호화합니다. 예를 들어, blackbox.yaml 이라는 파일을 사용합니다. Hiera () 함수를 사용하여 액세스 할 수 있습니다.
설정 : 검색 계층에 "Blackbox"를 추가하여 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
참고 : REPO는 .blackbox 대신 keyrings/live 사용할 수 있습니다. "구성은 어디에 저장되어 있습니까?"
.blackbox/blackbox-admins.txt 는 사용자가 파일을 해독 할 수있는 파일입니다. (보다 pedantically 파일이 암호화 된 gnupg 키 이름의 목록입니다.)
파일을 편집 할 수있는 사람들 목록에 가입하려면 세 단계가 필요합니다. GPG 키를 생성하고 키 링에 추가합니다. 그런 다음 이미 액세스 할 수있는 사람은 시스템에 귀하를 추가합니다. 마지막으로 액세스를 테스트해야합니다.
GPG 키가 아직 없으면 다음을 생성하는 방법은 다음과 같습니다.
gpg --gen-key
경고 : 새로운 버전의 GPG는 기존 버전의 GPG에서 이해하지 못하는 키를 생성합니다. 새 버전의 GPG로 키를 생성하면 이전 버전의 GPG 사용자에게 문제가 발생합니다. 따라서 BlackBox를 사용하는 모든 사람이 정확히 동일한 버전의 GPG를 가지고 있거나 GPG 버전을 BlackBox를 사용하는 모든 GPG의 오래된 버전과 같은 GPG 버전을 사용하여 GPG 키를 생성하는 것이 좋습니다.
암호화 설정에 대한 기본값을 선택, 0 만료. 아주 좋은 암호를 선택하십시오. 개인 키의 백업을 보관하십시오. 예를 들어, 백업 사본을 안전에 잠긴 USB 드라이브에 보관하십시오. 또는 적어도 인터넷 액세스가 거의 또는 전혀없는 안전한 기계에 넣고, 정식 암호화 등을 넣습니다. 고용주는 아마도 그러한 물건을 저장하는 방법에 대한 규칙이있을 것입니다.
참고 : 키를 생성하는 것이 느리면 일반적으로 시스템이 엔트로피를 충분히 생성하지 않기 때문입니다. 팁 : 해당 컴퓨터의 다른 창을 열고이 명령을 실행합니다. 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
그런 다음 repo로 밀어 넣습니다.
git push
or
ht push
(or whatever is appropriate)
참고 : 역할 계정 생성? 역할 계정의 pubring.gpg를 추가하는 경우 pubring.gpg 파일을 두 번째 매개 변수로 찾을 수있는 디렉토리를 지정할 수 있습니다 : blackbox_addadmin [email protected] /path/to/the/dir
이미 데이터 파일을 다시 암호화 할 액세스 권한이있는 사람에게 물어보십시오. 이것은 당신에게 액세스를 제공합니다. 그들은 단순히 변경하지 않고 데이터를 해독하고 다시 암호화합니다.
사전 확인 : 새 키가 좋아 보이는지 확인하십시오.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
예를 들어, 기업 표준을 준수하는지 키 이름 (이메일 주소)을 검사하십시오.
키 체인을 개인 키 체인으로 가져 와서 다시 암호화하십시오.
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
다시 암호화 된 파일을 푸시하십시오.
git commit -a
git push
or
hg commit
hg push
파일을 해독 할 수 있는지 확인하십시오. (제안 : 새로운 사람들이 연습 할 수 있도록 VCS로 더미 파일을 보관하십시오.)
기조 이름으로 blackbox_removeadmin 실행 한 다음 다시 암호화하십시오.
예:
blackbox_removeadmin [email protected]
blackbox_update_all_files
명령이 완료되면 변경 사항을 확인하고 밀어 붙이는 알림이 제공됩니다.
그들의 키는 여전히 열쇠 고리에 있지만 사용되지 않을 것입니다. 키링을 정리하려면 일반 GPG 명령을 사용하고 파일을 확인하십시오.
참고 : REPO는 .blackbox 대신 keyrings/live 사용할 수 있습니다. "구성은 어디에 저장되어 있습니까?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
참고 : REPO는 .blackbox 대신 keyrings/live 사용할 수 있습니다. "구성은 어디에 저장되어 있습니까?"
키 링에는 공개 키만 있습니다. 삭제할 비밀 키는 없습니다.
이 사람은 한 번에 모든 비밀에 접근 할 수 있다는 것을 기억하십시오. 그들은 사본을 만들 수있었습니다. 따라서 완전히 안전하려면 모든 암호를 변경하고 새로운 SSL 키를 생성하는 등의 권한이있는 액세스가있는 사람이 조직을 떠날 때와 마찬가지로 마찬가지로됩니다.
키의 신뢰성을 검증하는 것은 Blackbox가 달성 할 수없는 작업입니다. 이것은 수동으로 처리 해야하는 완전히 외부 주제입니다 (예 : 키 생성/관리와 동일한 방식) 또는 전용 메커니즘 (예 : 해당 워크 플로가있는 회사 CA)에 의해 포함됩니다. 신뢰 웹의 "일반적인"이점 (예 : 여기 또는 여기 참조) 외에도 몇 가지 오류를 방지합니다.
역사적으로 Blackbox는 "모든 키를 신뢰하는"모델을 사용하고 시행하고 있었지만 이것이 바뀌 었습니다! 이제 PGP/GPG Trust 모델을 사용하는지 여부와 방법에 대한 결정은 구성 (또는 PGP/GPG 기본값)에 의해 사용자에게 맡겨집니다.
Blackbox를 업데이트 할 때 사람들은 아직 사용중인 키의 신뢰성을 다루지 않은 경우 기능적 문제가 발생할 수 있습니다. 그렇게하고 지금 당신의 신뢰의 웹을 구축하기에 적합한시기입니다!
BlackBox가 사용하는 키의 무결성을 보장하는 외부 워크 플로우가있는 경우 PGP/GPG Trust 모델을 비활성화 하고이 워크 플로우에 의존 할 수 있습니다.
이는 "신뢰 모델 항상"를 선언하여 명령 줄 매개 변수를 전달하여 --trust-model=always PGP/GPG BINIGHT (ALIAS를 정의하거나 환경 변수를 사용하여 (예 : GPG="gpg2 --trust-model=always" 를 사용하여 수행 할 수 있습니다. GPG="gpg2 --trust-model=always" 또는 둘 다 조합) 또는 gpg.conf 에서 trust-model always 설정하여 (블랙 박스뿐만 아니라 모든 곳에서 신뢰의 웹을 비활성화 함).
경고 : 주요 검증을 전혀 사용하지 않는 것은 강력하게 불리합니다! 이것은 암호화 된 비밀의 기밀성을 우회하는 다양한 방법을 열어줍니다!
Blackbox는 구성 데이터를 .blackbox 하위 디렉토리에 저장합니다. 구식 저장소는 keyrings/live 사용합니다. 거꾸로 호환성을 위해 어느 쪽이든 작동합니다.
모든 문서는 .blackbox 를 나타냅니다.
디렉토리를 간단히 바꾸어 이전 리포를 변환 할 수 있습니다.
mv keyrings/live .blackbox
rmdir keyrings
사용자에게 덜 혼란 스럽다는 점을 제외하고 오래된 저장소를 변환 할 기술적 인 이유는 없습니다.
이 변경은 Commit 60E782A0, 릴리스 v1.20180615에서 이루어졌습니다.
세부 사항 :
$BLACKBOXDATA 확인합니다. 이 환경 변수가 설정되면 사용될 디렉토리입니다. 존재하지 않는 디렉토리가 나열되면 Blackbox는 오류를 인쇄하고 종료합니다.$BLACKBOXDATA 설정되지 않은 경우 : (일반적인 유스 케이스는)keyrings/live 시도하여 존재하는 경우 사용합니다..blackbox 사용됩니다. .blackbox 존재하지 않으면 BlackBox는 오류를 인쇄하고 종료합니다.개요 :
Git 또는 Mercurial Repo에 "Blackbox"를 추가하려면 다음을 수행해야합니다.
참고 : REPO는 .blackbox 대신 keyrings/live 사용할 수 있습니다. "구성은 어디에 저장되어 있습니까?"
당신은 당신의 길에 Blackbox의 "bin"디렉토리를 포함시키고 싶을 것입니다.
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
항원을 사용하는 경우 .zshrc에 antigen bundle StackExchange/blackbox 추가하면이 저장소를 다운로드하여 $ 경로에 추가합니다.
"새로운 사용자를 시스템에 교리하는 방법"에 대한 지침을 따르십시오. 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 커밋하지 말고 대신 삭제하십시오.
즉, 꼭두각시 마스터가 암호화되지 않은 데이터에 액세스 할 수있는 방법입니다.
참고 : REPO는 .blackbox 대신 keyrings/live 사용할 수 있습니다. "구성은 어디에 저장되어 있습니까?"
자동화 된 사용자 ( "역할 계정")는 암호화없이 해독 할 수 있어야하는 사용자입니다. 일반적으로 리포지트에서 마스터로 파일을 끌어내는 사용자를 위해이 작업을 수행하고 싶습니다. 이것은 Jenkins CI 또는 기타 CI 시스템으로 자동화 될 수 있습니다.
GPG 키에는 암호가 있어야합니다. 그러나 패스 프레이즈는 하위 키에서 선택 사항입니다. 따라서 암호를 사용하여 키를 생성 한 다음 암호화없이 서브 키를 만듭니다. 서브 키는 매우 강력하기 때문에 매우 안전한 기계에서 만들어야합니다.
또 다른 캐치가 있습니다. 역할 계정은 아마도 파일을 git/mercurial로 확인할 수 없습니다. 아마도 레포에 대한 읽기 전용에만 액세스 할 수있을 것입니다. 좋은 보안 정책입니다. 이것은 역할 계정을 사용하여 Subkey Public Bits를 Repo에 업로드 할 수 없음을 의미합니다.
따라서 우리는 안전한 기계에서 키/서브 키를 자신과 마찬가지로 만들 것입니다. 거기에서 우리는 공개 부분을 Repo에 커밋 할 수 있습니다. 또한이 계정에서 역할 계정에 필요한 부품을 내보내고 역할 계정에 액세스 할 수있는 위치로 복사 한 후 역할 계정으로 가져옵니다.
RIPIP : 엔트로피를 생성하도록 요청한 경우 다른 창에서 동일한 기계 에서이 실행을 고려하십시오. sudo dd if=/dev/sda of=/dev/null
이 문서의 나머지 경우 다음과 같은 대체를해야합니다.
참고 : 이것은보다 자동화/스크립트해야합니다. 패치를 환영합니다.
Securehost에서 꼭두각시 마스터의 키를 만듭니다.
$ 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]
참고 : 실제 이메일 주소가 아닌 호스트의 사용자 이름@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 구성을받습니다.
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가 제로 길이 파일인지 확인하십시오. 그렇지 않다면, 당신은 어떻게 든 Keyring에 개인 키를 추가했습니다. 다시 시작하십시오.
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.
PRIBIP : "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는 암호화를 중단합니다. 이 오류가 나타납니다.
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
참고 : REPO는 .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. - 사용자의 키가 만료되었으며 더 이상 암호화하는 데 사용할 수 없습니다. 만료 된 키 팁 교체를 따르십시오.
참고 : REPO는 .blackbox 대신 keyrings/live 사용할 수 있습니다. "구성은 어디에 저장되어 있습니까?"
파일을 리포에서 복사하면 해독 및 편집 할 수 있습니다. 분명히 편집, 키 변경 및 리포지션 밖에서 이루어지면 손실됩니다. 또한 명령은 기본 디렉토리에서 실행되는 경우에만 작동 할 가능성이 높습니다 (예 : 부모의 .Blackbox 디렉토리).
다음 명령은 다시 저장소에서 테스트되었습니다.
blackbox_postdeployblackbox_edit_startblackbox_edit_end 현재 구현은 전체 repo의 루트에 BlackBox /keyrings 저장합니다. 이렇게하면 뿌리가 다른 환경간에 문제가 생깁니다 (예 : 생산에서 개발 / /releases/foo 에 대한 체크 아웃 /개발). 이 문제를 해결하려면 export BLACKBOX_REPOBASE=/path/to/repo Repo의 특정 기반을 설정할 수 있습니다.
이것은 원래 GIT를 위해 작성되었으며 2 단계 커밋을 지원합니다. commit 은 로컬 커밋이며 "푸시"는 시스템에 등록되거나 시스템에 등록 될 때 버전 제어 서버로 상류로 변경을 보냅니다. 현재 구현은 blackbox_* 명령을 실행할 때 즉시 파일을 업스트림 파괴 서버에 commit .
일부 상황에서는 팀원 또는 자동화 된 역할이 시스템 GPG 버전 1.x와 함께 GPG 2.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
이것은 여러 시스템 테스트를 통해 실행됩니다. Repo, 파일을 암호화하고 파일을 해독하는 등을 만듭니다. 이 테스트를 실행하여 변경 사항이 아무것도 깨지지 않았는지 확인할 수 있습니다. 이 테스트를 사용하여 시스템이 새로운 운영 체제와 작동하는지 확인할 수도 있습니다.
코드 변경으로 테스트를 제출하십시오.
Blackbox를 변경하는 가장 좋은 방법은 테스트 중심 개발을 통한 것입니다. 먼저 tools/confidence.sh 에 테스트를 추가하십시오. 이 테스트는 실패해야하며, 변경하려는 변화의 필요성을 보여줍니다. 그런 다음 버그를 수정하거나 원하는 기능을 추가하십시오. 완료되면 모든 테스트를 통과 make confidence 합니다. 제출 한 PR에는 코드와 새로운 테스트가 포함되어야합니다. 이런 식으로 미래의 변화가 오래된 특징을 깨뜨리지 않는다는 것을 알면서 시스템이 커짐에 따라 신뢰 테스트가 축적됩니다.
참고 : 테스트는 현재 "git"을 가정하고 Centos, Mac OS X 및 Cygwin에서만 테스트되었습니다. 패치를 환영합니다!
다음은 Blackbox와 유사한 것을 수행하는 다른 오픈 소스 패키지입니다. 블랙 박스보다 더 좋아한다면 사용하십시오.
Git-Crypt는 최고의 git 통합을 가지고 있습니다. 일단 설정하면 사용자에게 거의 투명합니다. 그러나 그것은 Git과 만 작동합니다.
이 컨텐츠는 MIT 라이센스에 따라 해제됩니다. License.txt 파일을 참조하십시오.
