blackbox
v1.20220610
Almacene de forma segura secretos en un repositorio de VCS (es decir, Git, Mercurial, Subversion o Perforce). Estos comandos le facilitan los archivos específicos de GNU Privacy Guard (GPG) en un repositorio para que estén "encriptados en reposo" en su repositorio. Sin embargo, los scripts facilitan descifrarlos cuando necesita verlos o editarlos, y descifrarlos para su uso en producción. Originalmente escrito para Puppet, Blackbox ahora funciona con cualquier Git o Repositorio Mercurial.
ADVERTENCIA: El objetivo de este proyecto es ser un simple envoltorio alrededor de gpg para que usted y sus compañeros de trabajo no tengan que recordar que son todas esas banderas inescrutables y confusas. No está destinado a ser un sistema de cifrado sofisticado que resuelva todos los problemas o admite un gran número de archivos. El caso de uso ideal es mantener secretos en un servicio seguro como conjuros, AWS KMS, Azure Key Vault o GCP KMS; Luego use Blackbox para almacenar de forma segura las teclas API necesarias para acceder a ese sistema. De esa manera, está cifre un archivo único y pequeño. Se rechazarán las solicitudes de características para cualquier cosa más; No espere o incluso solicite "funciones empresariales". Si esto lo decepciona, considere un proyecto competitivo como https://www.agwa.name/projects/git-crypt
Una presentación de diapositivas (aproximadamente una liberación anterior) está en SlideShare.
Únase a nuestra lista de correo: https://groups.google.com/d/forum/blackbox-project
Supongamos que tiene un repositorio de VCS (es decir, un repositorio git o mercurial) y ciertos archivos contienen secretos como contraseñas o claves privadas SSL. A menudo, las personas solo almacenan dichos archivos "y esperan que nadie los encuentre en el repositorio". Eso no es seguro.
Con Blackbox, esos archivos se almacenan encriptados usando GPG. El acceso al repositorio de VCS sin tener las teclas GPG correctas hace que no tenga valor tener los archivos. Siempre que mantenga sus claves GPG seguras, no tiene que preocuparse por almacenar su repositorio de VCS en un servidor no confiable. ¡Diablos, incluso si confía en su servidor, ahora no tiene que confiar en las personas que hacen copias de seguridad de ese servidor, o las personas que manejan las cintas de copia de seguridad!
En lugar de una frase de GPG para todos los archivos, cada persona con acceso tiene sus propias claves GPG en el sistema. Cualquier persona con su clave GPG puede descifrar cualquier archivo. De esta manera, si una persona deja la empresa, no tiene que comunicar una nueva contraseña a todos con acceso. Simplemente deshabilite la única clave que ya no debería tener acceso. El proceso para hacer esto es tan fácil como ejecutar 2 comandos (1 para deshabilitar su clave, 1 para volver a cifrar todos los archivos).
Los procesos automatizados a menudo necesitan acceso a todos los archivos descifrados. Esto también es fácil. Por ejemplo, suponga que Git se está utilizando para archivos de marionetas. El maestro necesita acceso a la versión descifrada de todos los archivos. Simplemente configure una tecla GPG para el Puppet Master (o la cuenta de roles que empuja nuevos archivos al Puppet Master) y haga que ese usuario ejecute blackbox_postdeploy después de actualizar los archivos.
Si no tiene una tecla GPG, configúrela utilizando instrucciones como: Configurar la tecla GPG.
Ahora estás listo para ir.
cd en un repositorio GIT, Mercurial, Subversion o Perforce y ejecuta blackbox_initialize .
Si se va a encriptar un archivo, ejecute blackbox_register_new_file y termine.
Agregue y elimine las teclas con blackbox_addadmin y blackbox_removeadmin .
Para ver y/o editar un archivo, ejecute blackbox_edit ; Esto descifrará el archivo y se abrirá con lo que sea especificado por su variable de entorno de editor $.
Cuando cierre el editor, el archivo se encriptará automáticamente nuevamente y el archivo de texto sin formato temporal se triturará.
Si necesita dejar el archivo descifrado mientras actualiza, puede usar blackbox_edit_start para descifrar el archivo y blackbox_edit_end cuando desea "volver a colocarlo en el cuadro".
Obviamente, no queremos que se filtren cosas secretas como las claves privadas y contraseñas SSL.
Obviamente, no tan obviamente cuando almacenamos "secretos" en un repositorio de VCS como Git o Mercurial, de repente somos menos capaces de compartir nuestro código con otras personas. La comunicación entre los subteames de una organización está herido. También no puedes colaborar. O te encuentras enviando un correo electrónico a archivos individuales (¡qué aviso!), Haciendo un repositorio especial con los archivos necesarios por tus colaboradores (¡qué aviso!), O simplemente decidir que la colaboración no vale la pena todo ese esfuerzo (¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
La capacidad de ser abierta y transparente sobre nuestro código, con la excepción de algunos archivos específicos, es clave para el tipo de colaboración que los profesionales de DevOps y TI modernos deben hacer.
make copy-install copiará los archivos de bin en $ prefix/bin, predeterminado es/usr/local (desinstalar con make copy-uninstall ).make symlinks-install hará que los enlaces simbólicos de los archivos de bin en $ prefix/bin, predeterminado es/usr/local (desinstalado con make copy-uninstall ) (útil al hacer desarrollo)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm ; Ahora puede distribuir las RPM a través de métodos locales. (Requiere fpm.)make packages-deb ; Ahora puede distribuir el DEB a través de métodos locales. (Requiere fpm.)antigen bundle StackExchange/blackbox a su .zshrczgenom load StackExchange/blackbox a su .zshrc donde está cargando sus otros complementos.nix-shell -p blackboxpkgin in scm-blackbox| Nombre: | Descripción: |
|---|---|
blackbox_edit <file> | Decrypt, ejecutar $ editor, volver a encriptar un archivo |
blackbox_edit_start <file> | Descifrar un archivo para que pueda actualizarse |
blackbox_edit_end <file> | Cifrar un archivo después de que se usó blackbox_edit_start |
blackbox_cat <file> | Descifrar y ver el contenido de un archivo |
blackbox_view <file> | Como blackbox_cat pero las tuberías a less o $ buscapersonas |
blackbox_diff | Diff Decryptó archivos contra su versión crypida original |
blackbox_initialize | Habilitar Blackbox para un repositorio GIT o HG |
blackbox_register_new_file <file> | Cifrar un archivo por primera vez |
blackbox_deregister_file <file> | Eliminar un archivo de Blackbox |
blackbox_list_files | Enumere los archivos mantenidos por BlackBox |
blackbox_list_admins | Lista de administradores actualmente autorizados para Blackbox |
blackbox_decrypt_file <file> | Descifrar un archivo |
blackbox_decrypt_all_files | Descifrar todos los archivos administrados (interactivos) |
blackbox_postdeploy | Descifrar todos los archivos administrados (lote) |
blackbox_addadmin <gpg-key> | Agregue a alguien a la lista de personas que puedan cifrar/descifrar secretos |
blackbox_removeadmin <gpg-key> | Eliminar a alguien de la lista de personas que puedan cifrar/descifrar secretos |
blackbox_shred_all_files | Eliminar de forma segura cualquier archivo descifrado |
blackbox_update_all_files | Descifrar y luego volver a entrelazar todos los archivos. Útil después de que se cambian las claves |
blackbox_whatsnew <file> | Muestre lo que ha cambiado en la última confirmación para un archivo determinado |
Blackbox determina automáticamente qué VC está utilizando y hace lo correcto. Tiene una arquitectura enchufable para que sea fácil de extender a trabajar con otros sistemas. Se ha probado para trabajar con muchos sistemas operativos.
git - el githg - Mercurialsvn - Subversión (¡gracias, Ben Drasin!)p4 - Perforce.blackbox está intacto Para agregar o corregir soporte para un sistema VCS, busque código al final de bin/_blackbox_common.sh
Para agregar o corregir soporte para un nuevo sistema operativo, busque las declaraciones de casos en bin/_blackbox_common.sh y bin/_stack_lib.sh y tal vez tools/confidence_test.sh
Blackbox se puede usar con Cygwin, MingW o WSL2.
Blackbox asume que blackbox-admins.txt y blackbox-files.txt tendrán finales de línea LF. Los usuarios de Windows deben tener cuidado de configurar Git u otros sistemas para no convertir o "arreglar" esos archivos.
Si usa GIT, agregue las siguientes líneas a su archivo .gitattributes :
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
La última versión de blackbox_initialize creará un archivo .gitattributes en el directorio $BLACKBOXDATA (generalmente .blackbox ) para usted.
El soporte de Cygwin requiere los siguientes paquetes:
Operación normal:
Desarrollo (si puede agregar código y desea ejecutar la prueba de confianza)
El soporte de Mingw (viene con GIT para Windows) requiere lo siguiente:
Operación normal:
MINTTY en lugar de la consola de Windows. Ejecutará Blackbox desde el mensaje Git Bash.download.bat PATH=%PATH%;c:GnuWin32bin una vez que haya completado install.bat de ejecución.Desarrollo:
make test )Si recibe el siguiente error en WSL2, puede intentar configurar su entorno con las siguientes instrucciones (probado con Ubuntu 22.04 en WSL2):
~/.gnupg/gpg-agent.conf en WSL y agregue la siguiente línea: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeGPG tiene muchas formas diferentes de cifrar un archivo. Blackbox usa el modo que le permite especificar una lista de claves que pueden descifrar el mensaje.
Si tiene 5 personas ("administradores") que deberían poder acceder a los secretos, cada uno crea una clave GPG y agrega su clave pública al llavero. El comando GPG utilizado para cifrar los archivos enumera los 5 nombres de clave y, por lo tanto, cualquier clave 1 puede descifrar el archivo.
Para eliminar el acceso de alguien, elimine el nombre clave de ese administrador (es decir, la dirección de correo electrónico) de la lista de administradores y vuelva a cifrar todos los archivos. Todavía pueden leer el archivo .gpg (suponiendo que tengan acceso al repositorio) pero ya no pueden descifrarlo.
¿Qué pasa si mantuvieron una copia del antiguo repositorio antes de eliminar el acceso? Sí, pueden descifrar versiones antiguas del archivo. Es por eso que cuando un administrador deja al equipo, debe cambiar todas sus contraseñas, certificaciones SSL, etc. Deberías haber estado haciendo eso antes de Blackbox, ¿verdad?
¿Por qué no usas teclas simétricas? En otras palabras, ¿por qué meterse con todas estas cosas de la tecla GPG y, en cambio, por qué no cifiquemos todos los archivos con una sola frase? Sí, GPG lo admite, pero luego estamos administrando una contraseña compartida, que está llena de problemas. Si alguien "deja al equipo" tendríamos que comunicar a todos una nueva contraseña. Ahora solo tenemos que eliminar su llave. Esto escala mejor.
¿Cómo se descifra los procesos automatizados sin pedir una contraseña? GPG requiere una frase de pases en una clave privada. Sin embargo, permite la creación de subkeyos que no tienen frase de pases. Para los procesos automatizados, cree una subterránea que solo se almacene en la máquina que necesita descifrar los archivos. Por ejemplo, en Stack Exchange, cuando nuestro sistema de integración continua (CI) empuja un cambio de código a nuestros maestros de marionetas, ejecutan blackbox_postdeploy para descifrar todos los archivos. El usuario que ejecuta este código tiene una subterránea que no requiere una frase de contraseña. Como tenemos muchos maestros, cada uno tiene su propia clave. Y sí, esto significa que nuestros maestros de marionetas tienen que ser muy seguros. Sin embargo, ya estaban seguros porque, como, amigo ... si puedes entrar en el maestro de títeres de alguien, es dueño de su red.
Si usas Puppet, ¿por qué no usaste Hiera-Eyaml? Hay 4 razones:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a o hg commit Espera ... ¡puede ser incluso más fácil que eso! Ejecute blackbox_edit FILENAME , y descifrará el archivo en un archivo TEMP y llamará $EDITOR , volviendo a entrenarlo después de que el editor esté cerrado.
Ansible Vault proporciona funcionalidad para cifrar tanto archivos y cadenas almacenadas dentro de los archivos; Sin embargo, este módulo no maneja un seguimiento de las contraseñas requeridas para el descifrado.
En su lugar, se debe especificar un archivo de contraseña al ejecutar el libro de jugadas.
Ejemplo ansible para el archivo de contraseña: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
Alternativamente, se puede especificar esto en la variable de entorno ANSIBLE_VAULT_PASSWORD_FILE .
Los archivos completos, como los certificados SSL y las claves privadas, se tratan como archivos regulares. Los descifra cada vez que presionas un nuevo lanzamiento al Puppet Master.
Ejemplo de marioneta para un archivo encriptado: 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",
}
Las cadenas pequeñas, como contraseñas y claves API, se almacenan en un archivo Hiera Yaml, que cifra con blackbox_register_new_file . Por ejemplo, usamos un archivo llamado blackbox.yaml . Puede acceder a ellos usando la función HIERA ().
Configuración: Configurar hiera.yaml agregando "Blackbox" a la jerarquía de búsqueda:
:hierarchy:
- ...
- blackbox
- ...
En blackbox.yaml especificar:
---
module::test_password: "my secret password"
En su código de marionetas, acceda a la contraseña como lo haría con cualquier datos de Hiera:
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
La variable $the_password contendrá "mi contraseña secreta" y se puede usar en cualquier lugar que se usen las cadenas.
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
Se pueden especificar varios nombres de archivo en la línea de comando:
Ejemplo 1: Registro 2 de archivos:
blackbox_register_new_file file1.txt file2.txt
Ejemplo 2: Registre todos los archivos en $DIR :
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
Esto sucede raramente, pero lo tenemos cubierto:
blackbox_deregister_file path/to/file.name.key
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
.blackbox/blackbox-admins.txt es un archivo que enumera que los usuarios pueden descifrar archivos. (Más pedantosamente, es una lista de los nombres de clave GNUPG para los que está encriptado el archivo).
Para unirse a la lista de personas que pueden editar el archivo requiere tres pasos; Creas una tecla GPG y la agregas al anillo de llave. Entonces, alguien que ya tiene acceso lo agrega al sistema. Por último, debe probar su acceso.
Si aún no tiene una tecla GPG, aquí le mostramos cómo generar una:
gpg --gen-key
ADVERTENCIA: Las nuevas versiones de GPG generan claves que no son entendidas por versiones antiguas de GPG. Si genera una clave con una nueva versión de GPG, esto causará problemas a los usuarios de versiones anteriores de GPG. Por lo tanto, se recomienda que se asegure de que todos los que usan Blackbox tengan exactamente la misma versión de GPG, o generen teclas GPG utilizando una versión de GPG tan antigua como la versión más antigua de GPG utilizada por todos los que usan BlackBox.
Elija los valores predeterminados para la configuración de cifrado, 0 expiración. Elija una muy buena frase de pases. Almacene una copia de seguridad de la clave privada en algún lugar seguro. Por ejemplo, mantenga la copia de copia de seguridad en una unidad USB que está bloqueada en seguridad. O, al menos colóquelo en una máquina segura con poco o ningún acceso a Internet, cifrado de disco completo, etc. Su empleador probablemente tenga reglas sobre cómo almacenar tales cosas.
FYI: Si generar la clave es lenta, esto generalmente se debe a que el sistema no está generando suficiente entropía. Consejo: abra otra ventana en esa máquina y ejecute este comando: ls -R /
Ahora que tiene una tecla GPG, agrégase como administrador:
blackbox_addadmin KEYNAME
... donde "KeyName" está la dirección de correo electrónico que se enumera en la tecla GPG que creó anteriormente. Por ejemplo:
blackbox_addadmin [email protected]
Cuando el comando se completa con éxito, se emitirán instrucciones sobre cómo confirmar estos cambios. Ejecute el comando como se da para confirmar los cambios. Se verá así:
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
Luego empújalo al repositorio:
git push
or
ht push
(or whatever is appropriate)
Nota: ¿Creación de una cuenta de roles? Si está agregando el pubring.gpg de una cuenta de roles, puede especificar el directorio donde el archivo pubring.gpg se puede encontrar como un segundo parámetro: blackbox_addadmin [email protected] /path/to/the/dir
Pregúntele a alguien que ya tenga acceso para volver a encriptar los archivos de datos. Esto te da acceso. Simplemente descifran y vuelven a entrenar los datos sin hacer ningún cambio.
Pre-verificación: verifique que las nuevas teclas se vean bien.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
Por ejemplo, examine el nombre clave (dirección de correo electrónico) para asegurarse de que se ajuste a los estándares corporativos.
Importar el llavero en su llavero personal y reencyapt:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
Empuje los archivos reencyres:
git commit -a
git push
or
hg commit
hg push
Asegúrese de poder descifrar un archivo. (Sugerencia: Mantenga un archivo ficticio en VCS solo para que las nuevas personas practicen).
Simplemente ejecute blackbox_removeadmin con su nombre clave y luego vuelva a encrypt:
Ejemplo:
blackbox_removeadmin [email protected]
blackbox_update_all_files
Cuando se complete el comando, se le dará un recordatorio para verificar el cambio y presionarlo.
Tenga en cuenta que sus claves seguirán en el anillo de la llave, pero no se utilizarán. Si desea limpiar el llavero, use los comandos GPG normales y verifique el archivo.
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
El anillo de llaves solo tiene claves públicas. No hay claves secretas para eliminar.
Recuerde que esta persona tenía acceso a todos los secretos a la vez. Podrían haber hecho una copia. Por lo tanto, para estar completamente seguro, debe cambiar todas las contraseñas, generar nuevas claves SSL, y así sucesivamente, al igual que cuando cualquiera que haya tenido acceso privilegiado deja una organización.
Validar la confiabilidad de las claves es una tarea que Blackbox no puede lograr; Este es un tema completamente externo que debe tratarse manualmente (de la misma manera que generar/administrar su clave es, por ejemplo) o mediante un mecanismo dedicado (una empresa CA con flujos de trabajo correspondientes, por ejemplo). Además de los beneficios "comunes" de una red de confianza (ver aquí o aquí, por ejemplo), también evita varios errores.
Históricamente, Blackbox estaba usando y aplicando un modelo de "confianza cada clave", ¡pero esto ha cambiado! Ahora, la decisión de usar los modelos de confianza PGP/GPG de y cómo se deja al usuario mediante la configuración (o por los valores predeterminados PGP/GPG).
Al actualizar las personas blackbox, las personas pueden encontrar problemas funcionales si aún no han tratado la confianza de las claves que están usando. ¡Es el momento adecuado para hacerlo y creó su red de confianza ahora!
Si tiene un flujo de trabajo externo que garantiza la integridad de las teclas que usa Blackbox, es posible que desee deshabilitar los modelos PGP/GPG Trust y confiar en este flujo de trabajo.
Esto se puede lograr declarando "modelo de confianza siempre", ya sea pasando el parámetro de línea de comando --trust-model=always a su binario PGP/GPG cuando usa BlackBox (definiendo un alias o utilizando la variable de entorno (por ejemplo, GPG="gpg2 --trust-model=always" ) o una combinación de ambos) o estableciendo trust-model always en su gpg.conf (tenga en cuenta que esto deshabilita la red de confianza en todas partes, no solo para blackbox).
ADVERTENCIA: ¡Se desvanece fuertemente no utilizar ninguna validación clave! ¡Esto abre varias formas de evitar la confidencialidad de sus secretos cifrados!
Blackbox almacena sus datos de configuración en el subdirectorio .blackbox . Repos más antiguos usa keyrings/live . Porque la compatibilidad hacia atrás cualquiera funcionará.
Toda la documentación se refiere a .blackbox .
Puede convertir un repositorio antiguo simplemente renombrando el directorio:
mv keyrings/live .blackbox
rmdir keyrings
No hay una razón técnica para convertir los viejos repos, excepto que es menos confuso para los usuarios.
Este cambio se realizó en Commit 60E782A0, versión v1.20180615.
Los detalles:
$BLACKBOXDATA . Si se establece esta variable de entorno, este es el directorio que se utilizará. Si enumera un directorio que no existe, Blackbox imprimirá un error y saldrá.$BLACKBOXDATA no está configurado: (que es el caso de uso típico)keyrings/live y lo usará si existe..blackbox . Si .blackbox no existe, Blackbox imprimirá un error y saldrá.Descripción general:
Para agregar "Blackbox" a un repositorio git o mercurial, deberá hacer lo siguiente:
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
Querrá incluir el directorio "bin" de Blackbox en su camino:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
Si está utilizando antígeno, agregar antigen bundle StackExchange/blackbox a su .zshrc descargará este repositorio y lo agregará a su ruta $.
Siga las instrucciones de "¿Cómo adoctrinar a un nuevo usuario en el sistema?". Solo haz el paso 1.
Una vez hecho esto, es una buena idea probar el sistema asegurándose de que se pueda agregar un archivo al sistema (consulte "¿Cómo inscribir un nuevo archivo en el sistema?"), Y un usuario diferente puede descifrar el archivo.
Haga un archivo nuevo y regístrelo:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
Descifrarlo:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
Vuelva a encriptarlo:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
Solo debería ver foo.txt.gpg como foo.txt debería desaparecer.
El siguiente paso es cometer foo.txt.gpg y asegurarse de que otro usuario pueda verificar, ver y cambiar el contenido del archivo. Eso se deja como un ejercicio para el lector. Si tiene ganas de arriesgarse, no comete foo.txt.gpg y elimine en su lugar.
es decir, así es como un maestro de títeres puede tener acceso a los datos sin cifrar.
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
Un usuario automatizado (una "cuenta de roles") es uno que debe ser capaz de descifrar sin una frase. En general, querrá hacer esto para el usuario que extraiga los archivos del repositorio al maestro. Esto puede automatizarse con Jenkins CI u otro sistema CI.
Las teclas GPG tienen que tener una frase de pases. Sin embargo, las frases de contraseña son opcionales en las subkeyas. Por lo tanto, crearemos una llave con una frase de contraseña y luego crearemos una subproceso sin una frase de pases. Dado que la subpuesta es muy potente, debe crearse en una máquina muy segura.
Hay otra captura. La cuenta de roles probablemente no pueda verificar los archivos en Git/Mercurial. Probablemente solo tiene acceso de solo lectura al repositorio. Esa es una buena política de seguridad. Esto significa que la cuenta de roles no se puede usar para cargar los bits públicos subterráneos en el repositorio.
Por lo tanto, crearemos la llave/subclave en una máquina segura como usted. A partir de ahí, podemos cometer las porciones públicas en el repositorio. También a partir de esta cuenta exportaremos las piezas que necesita la cuenta de roles, las copiaremos donde la cuenta de roles pueda acceder a ellas e importarlas como la cuenta de roles.
Protip: si se le pide que genere entropía, considere ejecutar esto en la misma máquina en otra ventana: sudo dd if=/dev/sda of=/dev/null
Para el resto de este documento, deberá hacer las siguientes sustituciones:
Nota: Esto debería ser más automatizado/escrito. Parches bienvenidos.
En SecureHost, cree las teclas de Puppet Master:
$ mkdir /tmp/NEWMASTER
$ cd /tmp/NEWMASTER
$ gpg --homedir . --gen-key
Your selection?
(1) RSA and RSA (default)
What keysize do you want? (2048) DEFAULT
Key is valid for? (0) DEFAULT
# Real name: Puppet CI Deploy Account
# Email address: [email protected]
Nota: En lugar de una dirección de correo electrónico real, use el nombre de usuario@fqdn del host en la que se utilizará la clave. Si usa esta cuenta de roles en muchas máquinas, cada una debe tener su propia clave. Al usar el FQDN del host, podrá saber qué clave es cuál. En este documento, nos referiremos al nombre de usuario@fqdn como un nombre clave
¡Guarde la frase de pases en algún lugar seguro!
Cree una subpasa que no tenga contraseña:
$ 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
Ahora exporte de forma segura este directorio a Newmaster:
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
En Newmaster, reciba la nueva configuración de Gnupg:
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
Volver en SecureHost, agregue la nueva dirección de correo electrónico a .Blackbox/Blackbox-Admins.txt:
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
Verifique que Secring.gpg sea un archivo de longitud cero. Si no es así, de alguna manera ha agregado una clave privada al llavero. Empiece de nuevo.
cd .blackbox
ls -l secring.gpg
Comprometer los cambios recientes:
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
Regenere todos los archivos cifrados con la nueva clave:
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
En Newmaster, importe las claves y descifra los archivos:
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: Si obtienes "GPG: Decryption Falling: No Secret Key", entonces olvidó volver a encriptar Blackbox.yaml con la nueva clave.
En SecureHost, elimine de forma segura sus archivos:
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
También triture cualquier otro archivo temporal que haya hecho.
Si la clave de alguien ya ha expirado, Blackbox dejará de encriptar. Ves este error:
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
También puede detectar claves que están a punto de expirar emitiendo este comando y revisando manualmente las fechas "caducas:":
gpg --homedir=.blackbox --list-keys
o ... Lista de UID que caducarán dentro de 1 mes a partir de hoy: (ADVERTENCIA: Esto también enumera las claves sin una fecha de vencimiento)
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
Aquí le mostramos cómo reemplazar la clave:
ADVERTENCIA: Este proceso borrará los archivos sin cifrar que estuviera en el proceso de edición. Copielos en otro lugar y restaure los cambios cuando se realicen.
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
Cualquier archivo que se copiara temporalmente en el primer paso para no ser sobrescribido ahora se puede copiar y volver a encriptar con el comando blackbox_edit_end .
(¡Gracias a @chishaku por encontrar una solución a este problema!)
Es posible decirle a GIT que descifrue las versiones del archivo antes de ejecutarlos a través de git diff o git log . Para lograr esto DO:
.gitattributes en la parte superior del repositorio de git: *.gpg diff=blackbox
.git/config : [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
Y ahora comandos como git log -p file.gpg mostrarán un buen registro de los cambios en el archivo cifrado.
gpg: filename: skipped: No public key : por lo general, esto significa que hay un elemento en .blackbox/blackbox-admins.txt que no es el nombre de la clave. O se insertó algo inválido (como un nombre de archivo en lugar de un nombre de usuario) o un usuario ha dejado la organización y su clave se eliminó del llavero, pero su nombre no se eliminó del archivo Blackbox-AdMins.txt.
gpg: decryption failed: No secret key -Por lo general, significa que olvidó volver a encriptar el archivo con la nueva clave.
Error: can't re-encrypt because a key has expired. - La clave de un usuario ha expirado y no se puede usar para cifrar más. Siga la punta de las teclas caducadas reemplazar.
FYI: Su repositorio puede usar keyrings/live en lugar de .blackbox . Ver "¿Dónde se almacena la configuración?"
Si los archivos se copian con un repositorio, aún pueden ser descifrados y editados. Obviamente, edita, cambios en las teclas y tal se perderán si se hacen fuera del repositorio. También tenga en cuenta que los comandos tienen más probabilidades de funcionar solo si se ejecutan desde el directorio base (es decir, el padre al directorio .blackbox).
Los siguientes comandos han sido probados fuera de un repositorio:
blackbox_postdeployblackbox_edit_startblackbox_edit_end La implementación actual almacenará el BlackBox in /keyrings en la raíz de todo el repositorio. Esto creará un problema entre entornos que tienen diferentes raíces (es decir, verificar / encender el desarrollo vs /releases/foo en producción). Para evitar esto, puede export BLACKBOX_REPOBASE=/path/to/repo y establecer una base específica para su repositorio.
Esto se escribió originalmente para GIT y admite una confirmación de dos fases, en la que commit es una confirmación local y "Push" envía el cambio aguas arriba al servidor de control de versiones cuando algo está registrado o desregistrado con el sistema. La implementación actual commit inmediatamente un archivo (al servidor de subversión ascendente) cuando ejecute un comando blackbox_* .
En algunas situaciones, los miembros del equipo o los roles automatizados deben instalar GPG 2.x junto con el sistema GPG versión 1.x para ponerse al día con la versión GPG del equipo. En Ubuntu 16, puede apt-get install gnupg2 que instala el GPG2 binario. Si desea usar este binario GPG2, ejecute todos los comando BlackBox con GPG = GPG2.
Por ejemplo:
GPG=gpg2 blackbox_postdeploy
¡Agradecemos preguntas, informes de errores y comentarios!
El mejor lugar para comenzar es unirse a la lista de correo de BlackBox-Project y preguntar allí.
Los errores se rastrean aquí en Github. No dude en informar los errores usted mismo.
¡Las presentaciones de código son con gusto bienvenidas! El código es bastante fácil de leer.
Obtenga el código:
git clone [email protected]:StackExchange/blackbox.git
Pon a prueba tus cambios:
make confidence
Esto se ejecuta a través de una serie de pruebas del sistema. Crea un repositorio, cifra archivos, descifra archivos, etc. Puede ejecutar estas pruebas para verificar que los cambios que realizó no rompió nada. También puede usar estas pruebas para verificar que el sistema funcione con un nuevo sistema operativo.
Envíe pruebas con cambios en el código:
La mejor manera de cambiar Blackbox es a través del desarrollo impulsado por las pruebas. Primero agregue una prueba a tools/confidence.sh . Esta prueba debe fallar y demostrar la necesidad del cambio que está a punto de hacer. Luego solucione el error o agregue la función que desee. Cuando haya terminado, make confidence debe pasar todas las pruebas. El PR que envía debe incluir su código y la nueva prueba. De esta manera, las pruebas de confianza se acumulan a medida que el sistema crece a medida que sabemos que los cambios futuros no rompen las características antiguas.
Nota: Las pruebas actualmente suponen "GIT" y se han probado solo en CentOS, Mac OS X y Cygwin. Parches bienvenidos!
Aquí hay otros paquetes de código abierto que hacen algo similar a Blackbox. Si te gustan más que Blackbox, úsalos.
Git-Crypt tiene la mejor integración Git. Una vez configurado, es casi transparente para los usuarios. Sin embargo, solo funciona con Git.
Este contenido se publica bajo la licencia MIT. Vea el archivo License.txt.
