blackbox
v1.20220610
Armazene segredos com segurança em um repo VCS (ou seja, Git, Mercurial, Subversão ou Perforce). Esses comandos facilitam a criação de arquivos específicos de um repositório para que sejam "criptografados em repouso" em seu repositório. No entanto, os scripts facilitam a descriptografia quando você precisa visualizá -los ou editá -los e descriptografá -los para uso na produção. Originalmente escrito para o Puppet, o BlackBox agora funciona com qualquer repositório Git ou Mercurial.
AVISO: O objetivo deste projeto é ser um invólucro simples em torno gpg para que você e seus colegas de trabalho não precisem se lembrar de todas essas bandeiras inescrutáveis e confusas. Não se destina a ser um sistema de criptografia sofisticado que resolve todos os problemas ou suporta um grande número de arquivos. O caso de uso ideal é manter segredos em um serviço seguro, como Conjur, AWS KMS, Azure Key Vault ou GCP KMS; Em seguida, use o BlackBox para armazenar com segurança as teclas da API necessárias para acessar esse sistema. Dessa forma, você está criptografando um único arquivo, minúsculo. As solicitações de recursos para qualquer coisa mais serão rejeitadas; Não espere nem solicite "recursos corporativos". Se isso o decepcionar, considere um projeto concorrente como https://www.agwa.name/projects/git-crypt
Uma apresentação de slides (sobre uma liberação mais antiga) está no SlideShare.
Participe da nossa lista de discussão: https://groups.google.com/d/forum/blackbox-project
Suponha que você tenha um repositório VCS (ou seja, um repo Git ou Mercurial) e certos arquivos contêm segredos como senhas ou chaves privadas SSL. Muitas vezes, as pessoas armazenam esses arquivos "e esperam que ninguém os encontre no repositório". Isso não é seguro.
Com o BlackBox, esses arquivos são armazenados criptografados usando GPG. O acesso ao repo VCS sem também ter as teclas GPG corretas torna inútil ter os arquivos. Contanto que você mantenha suas teclas GPG seguras, não precisa se preocupar em armazenar seu repo VCS em um servidor não confiável. Caramba, mesmo se você confiar no seu servidor, agora não precisa confiar nas pessoas que fazem backups desse servidor ou as pessoas que lidam com as fitas de backup!
Em vez de uma senha de GPG para todos os arquivos, cada pessoa com acesso possui suas próprias teclas GPG no sistema. Qualquer arquivo pode ser descriptografado por qualquer pessoa com sua chave GPG. Dessa forma, se uma pessoa deixar a empresa, você não precisa comunicar uma nova senha a todos com acesso. Simplesmente desative a única chave que não deve mais ter acesso. O processo para fazer isso é tão fácil quanto executar 2 comandos (1 para desativar sua chave, 1 para criar todos os arquivos.)
Os processos automatizados geralmente precisam de acesso a todos os arquivos descriptografados. Isso também é fácil. Por exemplo, suponha que o GIT esteja sendo usado para arquivos de bonecos. O mestre precisa de acesso à versão descriptografada de todos os arquivos. Basta configurar uma chave GPG para o mestre de bonecos (ou a conta de função que empurra novos arquivos para o mestre de bonecos) e que esse usuário execute blackbox_postdeploy após a atualização de quaisquer arquivos.
Se você não tiver uma tecla GPG, configure -a usando instruções como: Configurar a tecla GPG.
Agora você está pronto para ir.
cd em um repositório Git, Mercurial, Subversão ou Perforce e execute blackbox_initialize .
Se um arquivo for criptografado, execute blackbox_register_new_file e você terminou.
Adicione e remova as teclas com blackbox_addadmin e blackbox_removeadmin .
Para visualizar e/ou editar um arquivo, execute blackbox_edit ; Isso descriptografará o arquivo e abrirá com o que for especificado pela sua variável de ambiente de editor $.
Quando você fecha o editor, o arquivo será automaticamente criptografado novamente e o arquivo de texto simples temporário será triturado.
Se você precisar sair do arquivo descriptografado enquanto atualiza, pode usar o blackbox_edit_start para descriptografar o arquivo e blackbox_edit_end quando deseja "colocá -lo de volta na caixa".
Obviamente, não queremos que coisas secretas, como as chaves e senhas privadas SSL, sejam vazadas.
Não é tão obviamente quando armazenamos "segredos" em um repo VCS como Git ou Mercurial, de repente somos menos capazes de compartilhar nosso código com outras pessoas. A comunicação entre as subtêms de uma organização é prejudicada. Você não pode colaborar também. Ou você se vê por e -mail arquivos individuais (eca!), Fazendo um repositório especial com apenas os arquivos necessários para seus colaboradores (eca !!) ou apenas decidir que a colaboração não vale todo esse esforço (eco !!!).
A capacidade de ser aberta e transparente em relação ao nosso código, com exceção de alguns arquivos específicos, é essencial para o tipo de colaboração que o DevOps e os praticantes modernos de TI precisam fazer.
make copy-install copiará os arquivos do bin para $ prefix/bin, o padrão é/usr/local (desinstale com make copy-uninstall ).make symlinks-install fará symblinks dos arquivos bin em $ prefix/bin, o padrão é/usr/local (desinstale com make copy-uninstall ) (útil ao fazer desenvolvimento)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm ; Agora você pode distribuir o RPM por meio de métodos locais. (Requer FPM.)make packages-deb ; Agora você pode distribuir o Deb por meio de métodos locais. (Requer FPM.)antigen bundle StackExchange/blackbox ao seu .zshrczgenom load StackExchange/blackbox ao seu .zshrc, onde você está carregando seus outros plugins.nix-shell -p blackboxpkgin in scm-blackbox| Nome: | Descrição: |
|---|---|
blackbox_edit <file> | Descriptografar, executar $ editor, re-criptografar um arquivo |
blackbox_edit_start <file> | Descriptografar um arquivo para que possa ser atualizado |
blackbox_edit_end <file> | Criptografar um arquivo depois que Blackbox_Edit_Start foi usado |
blackbox_cat <file> | Descriptografar e ver o conteúdo de um arquivo |
blackbox_view <file> | Como Blackbox_cat, mas tubos para less ou $ pager |
blackbox_diff | Diff descriptografou arquivos contra sua versão criptografada original |
blackbox_initialize | Ativar BlackBox para um repo Git ou HG |
blackbox_register_new_file <file> | Criptografar um arquivo pela primeira vez |
blackbox_deregister_file <file> | Remova um arquivo da BlackBox |
blackbox_list_files | Liste os arquivos mantidos pela BlackBox |
blackbox_list_admins | Listar os administradores atualmente autorizados para Blackbox |
blackbox_decrypt_file <file> | Descriptografar um arquivo |
blackbox_decrypt_all_files | Descriptografar todos os arquivos gerenciados (interativo) |
blackbox_postdeploy | Descriptografar todos os arquivos gerenciados (lote) |
blackbox_addadmin <gpg-key> | Adicione alguém à lista de pessoas que podem criptografar/descriptografar segredos |
blackbox_removeadmin <gpg-key> | Remova alguém da lista de pessoas que podem criptografar/descriptografar segredos |
blackbox_shred_all_files | Exclua com segurança todos os arquivos descriptografados |
blackbox_update_all_files | Descriptografar, em seguida, reencrince todos os arquivos. Útil após as chaves são alteradas |
blackbox_whatsnew <file> | Mostre o que mudou no último compromisso para um determinado arquivo |
O BlackBox determina automaticamente quais VCs você está usando e faz a coisa certa. Ele tem uma arquitetura de plug-in para facilitar a extensão do trabalho com outros sistemas. Foi testado para trabalhar com muitos sistemas operacionais.
git - o githg - Mercurialsvn - Subversão (obrigado, Ben Drasin!)p4 - Perforce.blackbox estiver intacto Para adicionar ou corrigir suporte para um sistema VCS, procure código no final do bin/_blackbox_common.sh
Para adicionar ou corrigir suporte para um novo sistema operacional, procure as instruções do caso em bin/_blackbox_common.sh e bin/_stack_lib.sh e talvez tools/confidence_test.sh
Blackbox pode ser usado com cygwin, mingw ou wsl2.
Blackbox assume que blackbox-admins.txt e blackbox-files.txt terão terminações de linha LF. Os usuários do Windows devem ter cuidado para configurar o Git ou outros sistemas para não converter ou "corrigir" esses arquivos.
Se você usar o Git, adicione as seguintes linhas ao seu arquivo .gitattributes :
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
A versão mais recente do blackbox_initialize criará um arquivo .gitattributes no diretório $BLACKBOXDATA (geralmente .blackbox ) para você.
O suporte de cygwin requer os seguintes pacotes:
Operação normal:
Desenvolvimento (se você adicionará código e deseja executar o teste de confiança)
Mingw (vem com o suporte Git for Windows) requer o seguinte:
Operação normal:
MINTTY em vez do console do Windows. Você estará executando o BlackBox a partir do prompt Git Bash.PATH=%PATH%;c:GnuWin32bin prompt de comando windows download do install.bat download.batDesenvolvimento:
make test )Se você receber o seguinte erro no WSL2, poderá tentar configurar seu ambiente com as seguintes instruções (testadas com o Ubuntu 22.04 no WSL2):
~/.gnupg/gpg-agent.conf no wsl e adicione a seguinte linha: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeO GPG tem muitas maneiras diferentes de criptografar um arquivo. O BlackBox usa o modo que permite especificar uma lista de chaves que podem descriptografar a mensagem.
Se você tem 5 pessoas ("Administradores") que devem acessar os segredos, cada uma cria uma chave GPG e adiciona sua chave pública ao chaveiro. O comando gpg usado para criptografar o arquivo lista todos os 5 nomes de chave e, portanto, qualquer tecla 1 pode descriptografar o arquivo.
Para remover o acesso de alguém, remova o nome da chave desse administrador (ou seja, endereço de e-mail) da lista de administradores e reencrie todos os arquivos. Eles ainda podem ler o arquivo .gpg (supondo que tenham acesso ao repositório), mas não podem mais descriptografá -lo.
E se eles mantiveram uma cópia do antigo repositório antes de remover o acesso? Sim, eles podem descriptografar versões antigas do arquivo. É por isso que quando um administrador sai da equipe, você deve alterar todas as suas senhas, certificados SSL e assim por diante. Você deveria estar fazendo isso antes da BlackBox, certo?
Por que você não usa teclas simétricas? Em outras palavras, por que mexer com todas essas coisas -chave GPG e, em vez disso, por que não apenas criptografamos todos os arquivos com uma única senha. Sim, o GPG suporta isso, mas estamos gerenciando uma senha compartilhada, que está repleta de problemas. Se alguém "deixar a equipe", teríamos que comunicar a todos uma nova senha. Agora só temos que remover sua chave. Isso escala melhor.
Como os processos automatizados descriptografam sem pedir uma senha? O GPG requer uma senha em uma chave privada. No entanto, permite a criação de subthays que não têm senha. Para processos automatizados, crie uma subchave que é armazenada apenas na máquina que precisa descriptografar os arquivos. Por exemplo, no Stack Exchange, quando nosso sistema de integração contínua (IC) empurra uma alteração de código para nossos mestres de fantoche, eles executam blackbox_postdeploy para descriptografar todos os arquivos. O usuário que executa este código possui uma subchave que não requer uma senha. Como temos muitos mestres, cada um tem sua própria chave. E, sim, isso significa que nossos mestres de marionetes precisam ser muito seguros. No entanto, eles já estavam seguros porque, tipo, cara ... se você pode invadir o mestre de bonecos de alguém, você possui a rede deles.
Se você usa fantoche, por que você não usou apenas Hiera-Eyaml? Existem 4 razões:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a ou hg commit Espere ... pode ser ainda mais fácil do que isso! Execute blackbox_edit FILENAME e descriptografará o arquivo em um arquivo temp e ligue para $EDITOR , reencritando novamente depois que o editor estiver fechado.
O Ansible Vault fornece funcionalidade para criptografar arquivos inteiros e strings armazenados nos arquivos; No entanto, acompanhar as senha (s) necessária para a descriptografia não é tratada por este módulo.
Em vez disso, é preciso especificar um arquivo de senha ao executar o manual.
Exemplo de Ansible para senha arquivo: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
Como alternativa, pode -se especificar isso na variável ANSIBLE_VAULT_PASSWORD_FILE .
Arquivos inteiros, como CERTs SSL e chaves particulares, são tratados como arquivos regulares. Você os descriptografar sempre que empurra um novo lançamento para o mestre de marionetes.
Exemplo de fantoche para um arquivo criptografado: 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",
}
Strings pequenas, como senhas e teclas de API, são armazenadas em um arquivo hiera yaml, que você criptografa com blackbox_register_new_file . Por exemplo, usamos um arquivo chamado blackbox.yaml . Você pode acessá -los usando a função hiera ().
Configuração: configure hiera.yaml adicionando "BlackBox" à hierarquia de pesquisas:
:hierarchy:
- ...
- blackbox
- ...
Em BlackBox.yaml Especifique:
---
module::test_password: "my secret password"
No seu código de fantoche, acesse a senha como você faria com que os dados da Hiera:
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
A variável $the_password conterá "minha senha secreta" e pode ser usada em qualquer lugar.
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
Vários nomes de arquivos podem ser especificados na linha de comando:
Exemplo 1: Registre 2 arquivos:
blackbox_register_new_file file1.txt file2.txt
Exemplo 2: Registre todos os arquivos em $DIR :
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
Isso acontece raramente, mas temos coberto:
blackbox_deregister_file path/to/file.name.key
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
.blackbox/blackbox-admins.txt é um arquivo que lista quais usuários podem descriptografar arquivos. (Mais pedantemente, é uma lista dos nomes de chave GNUPG para os quais o arquivo é criptografado.)
Participar da lista de pessoas que podem editar o arquivo requer três etapas; Você cria uma tecla GPG e a adiciona ao anel -chave. Então, alguém que já tem acesso o adiciona ao sistema. Por fim, você deve testar seu acesso.
Se você ainda não tem uma chave GPG, veja como gerar uma:
gpg --gen-key
AVISO: Novas versões do GPG geram teclas que não são entendidas por versões antigas do GPG. Se você gerar uma chave com uma nova versão do GPG, isso causará problemas para usuários de versões mais antigas do GPG. Portanto, é recomendável que você garante que todos que usem Blackbox tenham exatamente a mesma versão do GPG ou geram teclas GPG usando uma versão do GPG tão antiga quanto a versão mais antiga do GPG usada por todos que usam BlackBox.
Escolha os padrões para configurações de criptografia, 0 Expiração. Escolha uma senha muito boa. Armazene um backup da chave privada em algum lugar seguro. Por exemplo, mantenha a cópia de backup em uma unidade USB trancada em segurança. Ou, pelo menos, coloque-o em uma máquina segura com pouco ou nenhum acesso à Internet, Encripção de disco integral, etc. Seu empregador provavelmente tem regras sobre como armazenar essas coisas.
FYI: Se a geração da chave for lenta, isso geralmente ocorre porque o sistema não está gerando entropia suficiente. Dica: abra outra janela nessa máquina e execute este comando: ls -R /
Agora que você tem uma chave GPG, adicione -se como administrador:
blackbox_addadmin KEYNAME
... onde "Keyname" é o endereço de email listado na chave GPG que você criou anteriormente. Por exemplo:
blackbox_addadmin [email protected]
Quando o comando é concluído com êxito, as instruções sobre como comprometer essas alterações serão emitidas. Execute o comando dado para cometer as alterações. Vai ficar assim:
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
Em seguida, empurre -o para o repo:
git push
or
ht push
(or whatever is appropriate)
Nota: Criando uma conta de função? Se você estiver adicionando o pubring.gpg de uma conta de função, poderá especificar o diretório em que o arquivo pubring.gpg pode ser encontrado como um segundo parâmetro: blackbox_addadmin [email protected] /path/to/the/dir
Pergunte a alguém que já tem acesso para re-criar os arquivos de dados. Isso lhe dá acesso. Eles simplesmente descriptografaram e criptografam os dados sem fazer alterações.
Antecipação: Verifique se as novas teclas parecem boas.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
Por exemplo, examine o nome da chave (endereço de email) para garantir que ele esteja em conformidade com os padrões corporativos.
Importe o chaveiro para o seu chaveiro pessoal e reencrypt:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
Empurre os arquivos re-criptografados:
git commit -a
git push
or
hg commit
hg push
Verifique se você pode descriptografar um arquivo. (Sugestão: mantenha um arquivo fictício no VCS apenas para novas pessoas praticarem.)
Basta executar blackbox_removeadmin com seu nome de chave e depois reencrypt:
Exemplo:
blackbox_removeadmin [email protected]
blackbox_update_all_files
Quando o comando for concluído, você receberá um lembrete para verificar a alteração e empurrá -lo.
Observe que suas chaves ainda estarão no anel -chave, mas elas não serão utilizadas. Se você quiser limpar o chaveiro, use os comandos GPG normal e verifique o arquivo.
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
O anel -chave tem apenas chaves públicas. Não há chaves secretas para excluir.
Lembre -se de que essa pessoa teve acesso a todos os segredos ao mesmo tempo. Eles poderiam ter feito uma cópia. Portanto, para ser completamente seguro, você deve alterar todas as senhas, gerar novas teclas SSL e assim por diante, assim como quando qualquer um que tivesse acesso privilegiado deixa uma organização.
Validar a confiabilidade das chaves é uma tarefa que não pode ser realizada pela BlackBox; Este é um tópico completamente externo que deve ser tratado manualmente (da mesma maneira que gerar/gerenciar sua chave é, por exemplo) ou por um mecanismo dedicado (uma empresa CA com os fluxos de trabalho correspondentes, por exemplo). Além dos benefícios "comuns" de uma rede de confiança (veja aqui ou aqui, por exemplo), isso também impede vários erros.
Historicamente, a Blackbox estava usando e aplicando um modelo "confiar em todos os teclas", mas isso mudou! Agora, a decisão de se e como usar os modelos PGP/GPG Trust é deixada para o usuário por configuração (ou pelos padrões PGP/GPG).
Ao atualizar o BlackBox, as pessoas podem ter problemas funcionais se ainda não lidaram com a confiança das chaves que estão usando. É o momento certo para fazer isso e construir sua web de confiança agora!
Se você possui um fluxo de trabalho externo que garante que a integridade do Keys Blackbox use, você pode desativar os modelos de confiança PGP/GPG e confiar nesse fluxo de trabalho.
Isso pode ser conseguido declarando "Modelo de confiança sempre", passando pelo parâmetro da linha de comando --trust-model=always ao seu binário PGP/GPG ao usar o BlackBox (definindo um alias ou usando a variável de ambiente (por exemplo, GPG="gpg2 --trust-model=always" ) ou uma combinação de ambos) ou configurando trust-model always em seu gpg.conf (observe que isso desativa a rede de confiança em todos os lugares, não apenas para BlackBox).
Aviso: é fortemente desfavorecido para não usar nenhuma validação chave! Isso abre várias maneiras de ignorar a confidencialidade de seus segredos criptografados!
O BlackBox armazena seus dados de configuração no subdiretório .blackbox . Os repositórios mais antigos usam keyrings/live . Para compatibilidade com versões anteriores, também funcionará.
Toda a documentação refere -se a .blackbox .
Você pode converter um repo antigo simplesmente renomeando o diretório:
mv keyrings/live .blackbox
rmdir keyrings
Não há motivo técnico para converter repositórios antigos, exceto que é menos confuso para os usuários.
Essa alteração foi feita no commit 60E782A0, liberação v1.20180615.
Os detalhes:
$BLACKBOXDATA . Se essa variável de ambiente estiver definida, este é o diretório que será usado. Se ele listar um diretório que não existir, o BlackBox imprimirá um erro e sairá.$BLACKBOXDATA não estiver definido: (que é o caso de uso típico)keyrings/live e usará se houver..blackbox será usado. Se .blackbox não existir, o BlackBox imprimirá um erro e saída.Visão geral:
Para adicionar "BlackBox" a um repo Git ou Mercurial, você precisará fazer o seguinte:
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
Você vai querer incluir o diretório "bin" da Blackbox em seu caminho:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
Se você estiver usando o Antigen, adicionar antigen bundle StackExchange/blackbox ao seu .zshrc baixará este repositório e o adicionará ao seu $ PATH.
Siga as instruções para "como doutrinar um novo usuário no sistema?". Somente a etapa 1.
Uma vez feito isso, é uma boa idéia testar o sistema, certificando -se de que um arquivo possa ser adicionado ao sistema (consulte "Como inscrever um novo arquivo no sistema?"), E um usuário diferente pode descriptografar o arquivo.
Faça um novo arquivo e registre -o:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
Descriptografar:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
Revime-o:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
Você só deve ver foo.txt.gpg como foo.txt deve desaparecer.
A próxima etapa é cometer foo.txt.gpg e verifique se outro usuário pode verificar, visualizar e alterar o conteúdo do arquivo. Isso é deixado como um exercício para o leitor. Se você estiver com vontade de correr um risco, não comprometa foo.txt.gpg e exclua -o.
Ou seja, é assim que um mestre de marionetes pode ter acesso aos dados não criptografados.
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
Um usuário automatizado (uma "conta de função") é aquele que deve ser capaz de descriptografar sem uma senha. Em geral, você deseja fazer isso pelo usuário que puxa os arquivos do repositório para o mestre. Isso pode ser automatizado com o Jenkins CI ou outro sistema de IC.
As chaves GPG precisam ter uma senha. No entanto, as sessões de passas são opcionais em subthays. Portanto, criaremos uma chave com uma senha e depois criaremos uma subchave sem uma senha. Como a subchave é muito poderosa, ele deve ser criado em uma máquina muito segura.
Há outra captura. A conta de função provavelmente não pode verificar os arquivos no Git/Mercurial. Provavelmente só tem acesso somente leitura ao repositório. Essa é uma boa política de segurança. Isso significa que a conta de função não pode ser usada para fazer upload dos bits públicos da subchave no repositório.
Portanto, criaremos a chave/subcoração em uma máquina segura como você mesmo. A partir daí, podemos cometer as partes públicas no repositório. Também a partir desta conta, exportaremos as peças que a conta de função precisa, copiaremos -as para onde a conta da função pode acessá -las e as importará como a conta de função.
Protip: Se solicitado a gerar entropia, considere executar isso na mesma máquina em outra janela: sudo dd if=/dev/sda of=/dev/null
Para o restante deste documento, você precisará fazer as seguintes substituições:
Nota: Isso deve ser mais automatizado/script. Patches são bem -vindos.
No SecureHost, crie as chaves do mestre de marionetes:
$ 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]
Nota: Em vez de um endereço de e -mail real, use o nome de usuário@fqdn do host em que a chave será usada. Se você usar essa conta de função em muitas máquinas, cada uma deverá ter sua própria chave. Ao usar o FQDN do host, você poderá saber qual chave é qual. Neste documento, nos referiremos ao nome de usuário@fqdn como $ keyname
Salve a senha em algum lugar seguro!
Crie uma sub-chave que não tenha senha:
$ 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
Agora exporte com segurança este diretório para o Newmaster:
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
No Newmaster, receba a nova configuração do GNUPG:
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
De volta ao SecureHost, adicione o novo endereço de e-mail a .blackbox/Blackbox-admins.txt:
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
Verifique se o Secring.gpg é um arquivo de comprimento zero. Caso contrário, você adicionou uma chave privada ao chaveiro. Comece de novo.
cd .blackbox
ls -l secring.gpg
Cometer as mudanças recentes:
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
Regenerar todos os arquivos criptografados com a nova chave:
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
No Newmaster, importe as chaves e descriptografar os arquivos:
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: Se você obtém "GPG: Decripção falhou: nenhuma chave secreta", você esqueceu de reencriicar o BlackBox.yaml com a nova chave.
No SecureHost, exclua seus arquivos com segurança:
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
Também rasgue outros arquivos temporários que você pode ter feito.
Se a chave de alguém já expirou, o Blackbox parará de criptografar. Você vê este erro:
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
Você também pode detectar chaves que estão prestes a expirar, emitindo este comando e revisando manualmente as datas "expiradas:":
gpg --homedir=.blackbox --list-keys
Ou ... liste os UIDs que expirarão dentro de 1 mês a partir de hoje: (Aviso: isso também lista as chaves sem uma data de vencimento)
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
Veja como substituir a chave:
Aviso: esse processo apagará quaisquer arquivos não criptografados que você estivesse em processo de edição. Copie -os em outros lugares e restaure as alterações quando forem feitas.
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
Quaisquer arquivos que foram copiados temporariamente na primeira etapa para não ser substituídos agora podem ser copiados e reencrigados com o comando blackbox_edit_end .
(Obrigado a @chishaku por encontrar uma solução para esse problema!)
É possível dizer ao Git para descriptografar as versões do arquivo antes de executá -las através git diff ou git log . Para conseguir isso:
.gitattributes no topo do repositório Git: *.gpg diff=blackbox
.git/config : [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
E agora comandos como git log -p file.gpg mostrarão um bom log das alterações no arquivo criptografado.
gpg: filename: skipped: No public key -geralmente isso significa que há um item no .blackbox/blackbox-admins.txt que não é o nome da chave. Algo inválido foi inserido (como um nome de arquivo em vez de um nome de usuário) ou um usuário deixou a organização e sua chave foi removida do chaveiro, mas o nome deles não foi removido do arquivo Blackbox-admins.txt.
gpg: decryption failed: No secret key -geralmente significa que você esqueceu de criar o arquivo com a nova chave.
Error: can't re-encrypt because a key has expired. - A chave de um usuário expirou e não pode mais ser usada para criptografar. Siga a ponta das teclas de substituição expirada.
FYI: Seu repositório pode usar keyrings/live em vez de .blackbox . Veja "Onde está armazenado a configuração?"
Se os arquivos forem copiados de um repositório, eles ainda poderão ser descriptografados e editados. Obviamente, edições, alterações nas chaves, e isso será perdido se forem feitos fora do repositório. Observe também que os comandos têm maior probabilidade de funcionar apenas se executar no diretório base (ou seja, o pai para o diretório .BlackBox).
Os seguintes comandos foram testados fora de um repositório:
blackbox_postdeployblackbox_edit_startblackbox_edit_end A implementação atual armazenará o BlackBox in /keyrings na raiz de todo o repositório. Isso criará um problema entre ambientes que possuem raízes diferentes (ou seja, checando / sobre desenvolvimento vs /releases/foo na produção). Para contornar isso, você pode export BLACKBOX_REPOBASE=/path/to/repo e definir uma base específica para o seu repositório.
Isso foi originalmente escrito para o GIT e suporta uma confirmação em duas fases, na qual commit é um compromisso local e "push" envia a alteração a montante para o servidor de controle de versão quando algo é registrado ou desregrado ao sistema. A implementação atual commit imediatamente um arquivo (no servidor de subversão a montante) quando você executar um comando blackbox_* .
Em algumas situações, membros da equipe ou funções automatizadas precisam instalar o GPG 2.x ao lado da versão 1.x do sistema GPG para acompanhar a versão GPG da equipe. No Ubuntu 16, você pode apt-get install gnupg2 , que instala o GPG2 binário. Se você deseja usar este binário gpg2, execute todos os comando Blackbox com gpg = gpg2.
Por exemplo:
GPG=gpg2 blackbox_postdeploy
Congratulamo -nos com perguntas, relatórios de bugs e feedback!
O melhor lugar para começar é ingressar na lista de discussão Blackbox-Project e pedir lá.
Os insetos são rastreados aqui no Github. Por favor, sinta -se à vontade para relatar bugs por conta própria.
Os envios de código são bem -vindos de bom grado! O código é bastante fácil de ler.
Obtenha o código:
git clone [email protected]:StackExchange/blackbox.git
Teste suas alterações:
make confidence
Isso passa por vários testes do sistema. Ele cria um repositório, criptografa arquivos, descriptografa arquivos e assim por diante. Você pode executar esses testes para verificar se as alterações que você fez não quebraram nada. Você também pode usar esses testes para verificar se o sistema funciona com um novo sistema operacional.
Envie testes com alterações de código:
A melhor maneira de mudar o BlackBox é via desenvolvimento orientado a testes. Primeiro, adicione um teste às tools/confidence.sh . Este teste deve falhar e demonstrar a necessidade da mudança que você está prestes a fazer. Em seguida, corrija o bug ou adicione o recurso que você deseja. Quando terminar, make confidence deve passar em todos os testes. O PR que você envia deve incluir seu código e o novo teste. Dessa forma, os testes de confiança se acumulam à medida que o sistema cresce à medida que sabemos que as mudanças futuras não quebram recursos antigos.
Nota: Os testes atualmente assumem "git" e foram testados apenas em CentOS, Mac OS X e Cygwin. Patches são bem -vindos!
Aqui estão outros pacotes de código aberto que fazem algo semelhante ao BlackBox. Se você gosta mais deles do que o BlackBox, use -os.
O Git-Crypt tem a melhor integração do Git. Uma vez configurado, é quase transparente para os usuários. No entanto, ele só funciona com o Git.
Este conteúdo é liberado sob a licença do MIT. Consulte o arquivo License.txt.
