blackbox
v1.20220610
Безопасно хранить секреты в репо VCS (то есть GIT, Mercurial, Subversion или Perforce). Эти команды позволяют вам легко в GNU Privacy Guard (GPG) в репозиции шифровать конкретные файлы, чтобы они были «зашифрованы в состоянии покоя» в вашем репозитории. Тем не менее, сценарии позволяют легко расшифровать их, когда вам нужно просмотреть или отредактировать их, и расшифровывать их для использования в производстве. Первоначально написанный для Puppet, Blackbox теперь работает с любым репозиторием GIT или Mercurial.
Предупреждение: цель этого проекта - быть простой оберткой вокруг gpg , чтобы вы и ваши коллеги не должны помнить все эти непостижимые и запутанные флаги. Он не предназначен для сложной системы шифрования, которая решает все проблемы или поддерживает большое количество файлов. Идеальный вариант использования состоит в том, чтобы хранить секреты в безопасной службе, такой как Concur, AWS KMS, Vault Key Vault или KMS GCP; Затем используйте Blackbox для безопасного хранения клавиш API, необходимых для доступа к этой системе. Таким образом, вы шифруете один, крошечный файл. Показания функций для чего-либо еще будут отвергнуты; Не ожидайте и даже не запрашивайте «функции предприятия». Если это разочаровывает вас, пожалуйста, рассмотрите конкурентный проект, такой как https://www.agwa.name/projects/git-crypt
Слайд -презентация (о более старом выпуске) находится на слайдшре.
Присоединяйтесь к нашему списку рассылки: https://groups.google.com/d/forum/blackbox-project
Предположим, у вас есть репозиторий VCS (то есть GIT или Mercurial Repo), а некоторые файлы содержат секреты, такие как пароли или частные ключи SSL. Часто люди просто хранят такие файлы «и надеются, что никто не найдет их в репо». Это не безопасно.
С Blackbox эти файлы хранятся зашифрованы с использованием GPG. Доступ к VCS Repo без наличия правильных клавиш GPG делает бесполезным иметь файлы. Пока вы обеспечиваете безопасность своих клавиш GPG, вам не нужно беспокоиться о хранении вашего VCS -репо на ненадежном сервере. Черт, даже если вы доверяете своему серверу, теперь вам не нужно доверять людям, которые делают резервное копирование этого сервера, или людям, которые обрабатывают резервные ленты!
Вместо одной пассийной фразы GPG для всех файлов, каждый человек с доступом имеет свои собственные клавиши GPG в системе. Любой файл может быть расшифрован любым, у которого есть ключ GPG. Таким образом, если один человек покидает компанию, вам не нужно сообщать новый пароль всем с доступом. Просто отключите один ключ, который больше не должен иметь доступа. Процесс для этого так же прост, как и 2 команды (1, чтобы отключить их ключ, 1, чтобы повторно зашевелите все файлы.)
Автоматизированные процессы часто нуждаются в доступе ко всем расшифрованным файлам. Это тоже легко. Например, предположим, что GIT используется для марионеточных файлов. Мастер нуждается в доступе к расшифрованной версии всех файлов. Просто настройте ключ GPG для магистра марионеток (или учетной записи роли, которая выдвигает новые файлы в магистр марионеток) и попросите этого пользователя запустить blackbox_postdeploy после обновления любых файлов.
Если у вас нет ключа GPG, установите его, используя такие инструкции, как: Настройка клавиши GPG.
Теперь вы готовы к работе.
cd в GIT, ртутный, подрывной репозиторий или запустите blackbox_initialize .
Если файл должен быть зашифрован, запустите blackbox_register_new_file , и все готово.
Добавьте и удалите клавиши с помощью blackbox_addadmin и blackbox_removeadmin .
Чтобы просмотреть и/или отредактировать файл, запустите blackbox_edit ; Это расширит расшифровку файла и откроется с той, что указывается с вашей переменной среды $ Editor.
Когда вы закрываете редактор, файл будет автоматически зашифрован снова, и временный файл с открытым текстом будет измельчен.
Если вам нужно оставить дешифрованный файл во время обновления, вы можете использовать blackbox_edit_start , чтобы расшифровать файл и blackbox_edit_end , когда вы хотите «поместить его обратно в поле».
Очевидно, что мы не хотим, чтобы секретные вещи, такие как SSL -частные ключи и пароли, просочились.
Не так очевидно, что когда мы храним «секреты» в репотранте, как GIT или Mercurial, вдруг мы менее можем поделиться нашим кодом с другими людьми. Коммуникация между подразделениями организации пострадает. Вы также не можете сотрудничать. Либо вы обнаружите, что по электронной почте отдельные файлы (Yuck!), Создавая специальную репо с файлами, необходимыми вашим сотрудникам (Yuck !!), или просто решая, что сотрудничество не стоит всех усилий (Yuck !!!).
Возможность быть открытой и прозрачной в отношении нашего кода, за исключением нескольких конкретных файлов, является ключом к тому типу сотрудничества, которое должны делать DevOps и современные практики ИТ.
make copy-install будет скопировать файлы bin в $ prefix/bin, по умолчанию/usr/local (удаление с make copy-uninstall ).make symlinks-install сделает символики файлов bin в $ prefix/bin, по умолчанию/usr/local (удаление с make copy-uninstall ) (полезно при разработке)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm ; Теперь вы можете распространять RPM по локальным методам. (Требуется FPM.)make packages-deb ; Теперь вы можете распространять DEB по местным методам. (Требуется FPM.)antigen bundle StackExchange/blackbox к вашему .zshrczgenom load StackExchange/blackbox в ваш .ZSHRC, где вы загружаете другие плагины.nix-shell -p blackboxpkgin in scm-blackbox| Имя: | Описание: |
|---|---|
blackbox_edit <file> | Decrypt, запустите $ Editor, повторно закините файл |
blackbox_edit_start <file> | Обшифрует файл, чтобы его можно было обновить |
blackbox_edit_end <file> | Encrypt файл после использования Blackbox_Edit_Start |
blackbox_cat <file> | Расшифровывать и просмотреть содержимое файла |
blackbox_view <file> | Как blackbox_cat, но трубы less или $ pager |
blackbox_diff | Diff расшифрованные файлы против их исходной скрипной версии |
blackbox_initialize | Включить Blackbox для git или hg Repo |
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 | Decrypt Все управляемые файлы (партия) |
blackbox_addadmin <gpg-key> | Добавьте кого -нибудь в список людей, которые могут зашифровать/дешифровать секреты |
blackbox_removeadmin <gpg-key> | Удалить кого -то из списка людей, которые могут зашифровать/дешифровать секреты |
blackbox_shred_all_files | Безопасно удалить любые расшифрованные файлы |
blackbox_update_all_files | Затем Decrypt Recrypt Ell Files. Полезно после того, как ключи изменились |
blackbox_whatsnew <file> | Покажите, что изменилось в последнем коммите для данного файла |
Blackbox автоматически определяет, какие VCS вы используете, и делает правильные вещи. Он имеет плагин-архитектуру, чтобы облегчить расширение для работы с другими системами. Он был протестирован для работы со многими операционными системами.
git - githg - Меркуриальныйsvn - подрыв (спасибо, Бен Драсин!)p4 - Perforce.blackbox не поврежден Чтобы добавить или исправить поддержку системы VCS, ищите код в конце bin/_blackbox_common.sh
Чтобы добавить или исправить поддержку для новой операционной системы, ищите операторы корпуса в bin/_blackbox_common.sh и bin/_stack_lib.sh и, возможно, tools/confidence_test.sh
Blackbox можно использовать с Cygwin, Mingw или WSL2.
Blackbox предполагает, что blackbox-admins.txt и blackbox-files.txt будут иметь концовки LF Line. Пользователи Windows должны быть осторожны, чтобы настроить GIT или другие системы, чтобы не преобразовать или «исправить» эти файлы.
Если вы используете git, добавьте следующие строки в свой файл .gitattributes :
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
Последняя версия blackbox_initialize создаст файл .gitattributes в каталоге $BLACKBOXDATA (обычно .blackbox ) для вас.
Поддержка Cygwin требует следующих пакетов:
Нормальная работа:
Разработка (если вы будете добавлять код и хотите запустить тест на доверие)
Поддержка Mingw (поставляется с GIT для Windows). Требуется следующее:
Нормальная работа:
MINTTY вместо консоли Windows. Вы будете выполнять Blackbox из подсказки Git Bash.download.bat , как только он завершит run install.bat , затем добавьте путь для этих инструментов в ваш путь (Ex: PATH=%PATH%;c:GnuWin32bin )Разработка:
make test требуются какие -либо дополнительные пакеты.Если вы получите следующую ошибку в WSL2, вы можете попытаться настроить свою среду со следующими инструкциями (протестировано с Ubuntu 22.04 на WSL2):
~/.gnupg/gpg-agent.conf на wsl и добавьте следующую строку: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeGPG имеет много разных способов шифрования файла. Blackbox использует режим, который позволяет указать список ключей, которые могут расшифровать сообщение.
Если у вас есть 5 человек («администраторы»), которые должны быть в состоянии получить доступ к секретам, каждый создает ключ GPG и добавляет свой открытый ключ в ключ. Команда GPG, используемая для шифрования файла, перечисляет все 5 имен ключей, и, следовательно, любая 1 клавиша может расшифровать файл.
Чтобы удалить чей-либо доступ, удалите ключевое имя этого администратора (т.е. адрес электронной почты) из списка администраторов и повторно зашевелите все файлы. Они все еще могут прочитать файл .gpg (при условии, что у них есть доступ к репозиторию), но они больше не могут его расшифровать.
Что, если они сохранили копию старого репо, прежде чем убрать доступ? Да, они могут расшифровать старые версии файла. Вот почему, когда администратор покидает команду, вы должны изменить все свои пароли, SSL Certs и так далее. Вы должны были делать это до Blackbox, верно?
Почему бы вам не использовать симметричные ключи? Другими словами, зачем связываться со всеми этими ключами GPG, и вместо этого мы просто не зашифруем все файлы с помощью одной пассийной фразы. Да, GPG поддерживает это, но тогда мы управляем общим паролем, который чреват проблемы. Если кто -то «покинет команду», нам придется сообщить всем новый пароль. Теперь нам просто нужно удалить их ключ. Это масштабируется лучше.
Как автоматические процессы расшифровывают, не прося пароль? GPG требует пассисной фразы на закрытом ключе. Тем не менее, это позволяет создавать подказки, у которых нет пассажирской фразы. Для автоматических процессов создайте подкей, который хранится только на машине, которая должна расшифровать файлы. Например, при обмене стека, когда наша система непрерывной интеграции (CI) нажимает изменение кода для наших марионеточных мастеров, они запускают blackbox_postdeploy , чтобы расшифровать все файлы. Пользователь, который запускает этот код, имеет подкаус, который не требует пассажирской фразы. Поскольку у нас много мастеров, у каждого есть свой ключ. И, да, это означает, что наши марионетки должны быть очень безопасными. Тем не менее, они уже были в безопасности, потому что, как, чувак ... если вы можете ворваться в чей -то марионеточный мастер, вы владеете своей сетью.
Если вы используете Puppet, почему вы просто не использовали Hiera-Eyml? Есть 4 причины:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a или hg commit Подожди ... это может быть даже проще, чем это! Запустите blackbox_edit FILENAME , и оно расшифрует файл в временном файле и вызовите на нем $EDITOR , снова повторно зашевелитесь после закрытия редактора.
Ansible Vault обеспечивает функциональность для шифрования как целых файлов, так и строк, хранящихся в файлах; Тем не менее, отслеживание пароля, необходимого для дешифрования, не обрабатывается этим модулем.
Вместо этого нужно указать файл пароля при запуске Playbook.
Ansible Пример для файла пароля: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
В качестве альтернативы можно указать это в переменной среды ANSIBLE_VAULT_PASSWORD_FILE .
Целые файлы, такие как SSL Certs и частные ключи, обрабатываются так же как обычные файлы. Вы расшифровываете их в любое время, когда вы подталкиваете новый релиз к мастеру марионеток.
Пример марионетки для зашифрованного файла: 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 ().
Настройка: настроить hiera.yaml , добавив «Blackbox» в иерархию поиска:
: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
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
.blackbox/blackbox-admins.txt -это файл, в котором перечислены, какие пользователи могут расшифровать файлы. (Более педантично, это список имен ключей GNUPG, которые файл зашифрован для.)
Чтобы присоединиться к списку людей, которые могут редактировать файл, требуется три шага; Вы создаете клавишу GPG и добавляете его в кольцо клавиши. Затем кто -то, у кого уже есть доступ, добавляет вас в систему. Наконец, вы должны проверить свой доступ.
Если у вас еще нет ключа GPG, вот как его генерировать:
gpg --gen-key
Предупреждение: новые версии GPG генерируют ключи, которые не понимаются старыми версиями GPG. Если вы генерируете ключ с новой версией GPG, это вызовет проблемы для пользователей более старых версий GPG. Поэтому рекомендуется либо убедиться, что у всех, кто использует Blackbox, есть та же самая версия GPG, либо генерировать клавиши GPG, используя версию GPG, такую же старую, как самая старая версия GPG, используемая всеми, использующими BlackBox.
Выберите значения по умолчанию для настройки шифрования, 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
Затем подтолкните его к репо:
git push
or
ht push
(or whatever is appropriate)
Примечание: создание ролевой учетной записи? Если вы добавляете pubring.gpg учетной записи роли, вы можете указать каталог, в котором файл pubring.gpg можно найти в виде 2-го параметра: blackbox_addadmin [email protected] /path/to/the/dir
Спросите кого-нибудь, кто уже имеет доступ к повторному затенению файлов данных. Это дает вам доступ. Они просто расшифровывают и повторно зашевелились данные, не внося никаких изменений.
Предварительная проверка: проверьте новые ключи хорошо выглядят.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
Например, изучите ключевое имя (адрес электронной почты), чтобы убедиться, что оно соответствует корпоративным стандартам.
Импортируйте ключей в свой личный брелок и переиздание:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
Нажмите на повторную зашифрованную файлы:
git commit -a
git push
or
hg commit
hg push
Убедитесь, что вы можете расшифровать файл. (Предложение: держите фиктивное файл в капельнице только для того, чтобы новые люди могли практиковать.)
Просто запустите blackbox_removeadmin с их именем ключи, затем повторно заморожены:
Пример:
blackbox_removeadmin [email protected]
blackbox_update_all_files
Когда команда завершится, вам будет дано напоминание, чтобы проверить изменение и протолкнуть его.
Обратите внимание, что их ключи все еще будут в кольце ключа, но они останутся неиспользованными. Если вы хотите очистить Keyring, используйте обычные команды GPG и проверьте файл.
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
Кольцо с ключом имеет только общедоступные ключи. Там нет секретных ключей для удаления.
Помните, что у этого человека был доступ ко всем секретам за один раз. Они могли сделать копию. Поэтому, чтобы быть полностью безопасным, вы должны изменить все пароли, генерировать новые клавиши SSL и так далее, как если бы любой, кто имел привилегированный доступ, оставляет организацию.
Проверка достоверности ключей - это задача, которая не может быть выполнена Blackbox; Это совершенно внешняя тема, с которой необходимо решать вручную (например, создание/управление вашим ключом) или с помощью специального механизма (компания CA с соответствующими рабочими процессами, например). Помимо «общих» преимуществ доверия (см. Здесь или здесь, например), это также предотвращает несколько ошибок.
Исторически Blackbox использовал и обеспечивал модель «доверять каждый ключ», но это изменилось! Теперь решение о том, как и как использовать модели доверия PGP/GPG, оставляется пользователем по конфигурации (или по умолчанию PGP/GPG).
При обновлении Blackbox люди могут столкнуться с функциональными проблемами, если они еще не справились с доверимостью ключей, которые они используют. Это подходящее время, чтобы сделать это и создать вашу сеть доверия сейчас!
Если у вас есть внешний рабочий процесс, который обеспечивает целостность ключей Blackbox, вы можете отключить модели доверия PGP/GPG и полагаться на этот рабочий процесс.
Это может быть достигнуто, объявив «Модель доверия всегда», либо путем передачи параметра командной строки --trust-model=always в ваш двоичный файл PGP/GPG при использовании BlackBox (определяя псевдоним или используя переменную среды (например, GPG="gpg2 --trust-model=always" ) или комбинация обоих) или путем установки trust-model always в gpg.conf (обратите внимание, что это отключает сеть доверия повсюду, а не только для Blackbox).
ПРЕДУПРЕЖДЕНИЕ: Тревожно не использовать никаких ключевых валидаций вообще! Это открывает различные способы обойти конфиденциальность ваших зашифрованных секретов!
Blackbox сохраняет свои данные конфигурации в подкаталоге .blackbox . Старые репо используют keyrings/live . Для обратной совместимости либо будет работать.
Вся документация относится к .blackbox .
Вы можете преобразовать старое репо, просто переименовав каталог:
mv keyrings/live .blackbox
rmdir keyrings
Нет технических причин для преобразования старых репо, за исключением того, что это менее запутанно для пользователей.
Это изменение было сделано в Commit 60E782A0, выпуск V1.20180615.
Детали:
$BLACKBOXDATA . Если эта переменная среды установлена, это будет использоваться каталог. Если в нем перечислены каталог, которого не существует, Blackbox печатает ошибку и выходит.$BLACKBOXDATA не установлена: (который является типичным вариантом использования)keyrings/live и использует его, если он существует..blackbox . Если .blackbox не существует, Blackbox напечатает ошибку и выйдет.Обзор:
Чтобы добавить «Blackbox» в git или mercurial Repo, вам нужно сделать следующее:
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
Вы захотите включить каталог Blackbox "Bin" на свой путь:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
Если вы используете антиген, добавление antigen bundle StackExchange/blackbox в ваш .zshrc загрузит этот репозиторий и добавит его в свой путь $.
Следуйте инструкциям «Как разместить нового пользователя в системе?». Только шаг 1.
Как только это будет сделано, является ли хорошей идеей протестировать систему, убедившись, что в систему можно добавить файл (см. «Как зарегистрировать новый файл в систему?»), И другой пользователь может расшифровать файл.
Сделайте новый файл и зарегистрируйте его:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
Дешифрируйте это:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
Повторно закипите на него:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
Вы должны видеть только foo.txt.gpg как foo.txt который должен исчезнуть.
Следующим шагом является совершение foo.txt.gpg и убедиться, что другой пользователь может проверить, просмотреть и изменить содержимое файла. Это осталось как упражнение для читателя. Если вы хотите рискнуть, не совершайте foo.txt.gpg и вместо этого удаляйте его.
т.е. так марионеточный мастер может иметь доступ к незашифрованным данным.
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
Автоматизированный пользователь («учетная запись роли») - это тот, который должен быть в состоянии расшифровать без пассисной фразы. В общем, вы захотите сделать это для пользователя, который вытаскивает файлы из репо до мастера. Это может быть автоматизировано с помощью Jenkins CI или другой системы CI.
Клавиши GPG должны иметь пасфразу. Тем не менее, пасфразы являются необязательными на подкинках. Поэтому мы создадим ключ с пассивной фразой, а затем создадим подкей без пасфразы. Поскольку подкаушка очень мощный, он должен быть создан на очень безопасной машине.
Есть еще один улов. Ролевая учетная запись, вероятно, не может проверить файлы в GIT/Mercurial. Вероятно, он имеет только доступ к чтению к репо. Это хорошая политика безопасности. Это означает, что ролевая учетная запись не может быть использована для загрузки подкеди публичных битов в репо.
Поэтому мы создадим ключ/подк -ключ на безопасной машине, как и вы сами. Оттуда мы можем совершить общественные части в репо. Кроме того, из этой учетной записи мы будем экспортировать детали, которые нуждаются в ролевой учетной записи, скопируйте их туда, где ролевая учетная запись может получить к ним доступ, и импортировать их в качестве ролевой учетной записи.
Protip: Если попросить сгенерировать энтропию, рассмотрите возможность запустить ее на той же машине в другом окне: 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 хоста, вы сможете узнать, какой ключ какой. В этом документе мы будем называть имя пользователя@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.
Protip: Если вы получите «GPG: Decryption не удалось: без секретного ключа», то вы забыли повторно зашевить 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.
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
Вы также можете обнаружить ключи, которые собираются истечь, выпустив эту команду и вручную просмотрев «Срок действия»: даты:
gpg --homedir=.blackbox --list-keys
Или ... Список UIDS, которые истекают в течение 1 месяца с сегодняшнего дня: (Предупреждение: в нем также перечислены ключи без срока годности)
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 расшифровывает версии файла, прежде чем запустить их через git log git diff или GIT. Чтобы достичь этого:
.gitattributes в верхней части репозитория GIT: *.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-dmins.txt.
gpg: decryption failed: No secret key -обычно означает, что вы забыли повторно зашевить файл с новым ключом.
Error: can't re-encrypt because a key has expired. - Ключ пользователя истек и больше не может быть использован для шифрования. Следуйте замену срок действия срока действия клавиш.
К вашему сведению: ваше репо может использовать keyrings/live вместо .blackbox . Смотрите "Где хранится конфигурация?"
Если файлы скопированы из репо, они все еще могут быть расшифрованы и отредактированы. Очевидно, что изменения, изменения в ключах и такие будут потеряны, если они сделаны вне репо. Также обратите внимание, что команды, скорее всего, будут работать только в случае запуска из базового каталога (т.е. родитель в каталог .blackbox).
Следующие команды были проверены вне репо:
blackbox_postdeployblackbox_edit_startblackbox_edit_end Текущая реализация будет хранить Blackbox In /keyrings в корне всего репо. Это создаст проблему между средами, которые имеют разные корни (т.е. проверка / на разработку против /releases/foo в производстве). Чтобы обойти это, вы можете export BLACKBOX_REPOBASE=/path/to/repo и установить определенную базу для вашего репо.
Первоначально это было написано для GIT и поддерживает двухфазный коммит, в котором commit -локальный коммит, а «push» отправляет изменение вверх по течению на сервер управления версиями, когда что-то зарегистрировано или снято с системой. Текущая реализация немедленно commit файл (на сервер подверсл) при выполнении команды blackbox_* .
В некоторых ситуациях члены команды или автоматизированные роли должны установить GPG 2.x вместе с системой версии GPG GPG, чтобы догнать версию GPG команды. На Ubuntu 16 вы apt-get install gnupg2 , который устанавливает двоичный GPG2. Если вы хотите использовать этот двоичный файл GPG2, запустите каждую команду Blackbox с помощью GPG = GPG2.
Например:
GPG=gpg2 blackbox_postdeploy
Мы приветствуем вопросы, отчеты об ошибках и отзывы!
Лучшее место для начала-присоединиться к списку рассылки Blackbox-Project и спросить там.
Ошибки отслеживаются здесь, в GitHub. Пожалуйста, не стесняйтесь сообщать о ошибках самостоятельно.
Кодовые материалы с радостью приветствуются! Код довольно легко читать.
Получите код:
git clone [email protected]:StackExchange/blackbox.git
Проверьте свои изменения:
make confidence
Это проходит через ряд системных тестов. Он создает репо, шифрует файлы, расшифровывает файлы и так далее. Вы можете запустить эти тесты, чтобы убедиться, что внесенные вами изменения ничего не сломали. Вы также можете использовать эти тесты, чтобы убедиться, что система работает с новой операционной системой.
Пожалуйста, отправьте тесты с изменениями кода:
Лучший способ смены Blackbox - это разработка испытаний. Сначала добавьте тест в tools/confidence.sh . Этот тест должен потерпеть неудачу и продемонстрировать необходимость в изменении, которое вы собираетесь внести. Затем исправьте ошибку или добавьте нужную функцию. Когда вы закончите, make confidence , должна пройти все тесты. PR, который вы отправляете, должен включать ваш код, а также новый тест. Таким образом, конфиденциальные тесты накапливаются по мере роста системы, поскольку мы знаем, что будущие изменения не нарушают старые функции.
Примечание. В настоящее время тесты предполагают «git» и были протестированы только на CentOS, Mac OS X и Cygwin. Патчи приветствуются!
Вот другие пакеты с открытым исходным кодом, которые делают что -то похожее на Blackbox. Если они вам нравятся больше, чем Blackbox, используйте их.
Git-Crypt имеет лучшую интеграцию GIT. После настройки он почти прозрачен для пользователей. Однако это работает только с GIT.
Этот контент выпускается по лицензии MIT. См. Файл License.txt.
