Как и многие инструменты Linux, git-crypt является примером того, как делать только одно и делать это хорошо. Эта философия гласит, что ни одна утилита не пытается предоставить целый набор инструментов или экосистему, только одну функцию, которая может быть связана с другими, как вам нравится. В этом случае git-crypt не выставляет себя за инструмент развертывания и не имеет каких-либо конкретных интеграций в рабочий процесс. Его задача - просто позволить git-хранилищу хранить конфиденциальные данные, которые могут быть использованы в некоторых проверках, но не в других. Варианты использования могут различаться, как и цепочка с другими инструментами.
Исходя из формулировки вашего вопроса, я бы также уточнил, что git-crypt не является "секретным решением". На самом деле это совсем не хранит ваши секреты, а позволяет просто перетасовать, где вы их храните. В этом случае он позволяет хранить секретные данные в хранилище вместе с несекретной информацией, но делает это только за счет возложения секретного бремени на другой инструмент. Он обменивает один секрет на другой: секретный компонент (ы) вашего проекта, контролируемый версией, для ключа GPG. Как вы управляете секретом, все еще зависит от вас, но теперь секрет, который вы должны обработать, - это ключ GPG.
Хранение секретов до вас. В случае с вами и другими разработчиками это, вероятно, означает наличие файла личного ключа GPG, работающего в вашем домашнем каталоге, который, как мы надеемся, будет защищен парольной фразой, которая вводится в агент перед передачей другим программам, таким как git-crypt, которые его вызывают.
В случае возможности автоматического развертывания программного обеспечения на сервере чему-то где-то нужно доверять с настоящими секретами. Часто это инструмент верхнего уровня, например Ansible или Puppet , или, возможно, среда CI, такая как Gitlab , Travis или Круг . Обычно вы не доверяете ничему, кроме инструмента развертывания высшего уровня, зная, когда вводить секреты в среду, а когда нет (или в случае сред разработки / промежуточной / рабочей среды, , которые секреты вводить) .
Я не знаком с Circle, но знаю, что с Тревисом в ваших проектах Настройки * На вкладке 1032 * есть раздел Переменные среды , который можно использовать для передачи личной информации в виртуальную машину. , Существует некоторая документация о том, как это использовать. Сборка Gitlab в CI-системе имеет что-то похожее и может передавать различные секреты для тестирования или развертывания сред и т. Д.
Я бы предложил наиболее вероятный вариант использования для вашего рабочего процесса:
- Создайте специальную секретную переменную для использования на ваших производственных машинах, в которой есть пароль для ключа GPG, используемого только для развертываний. Все, что вы используете для создания своих машин, должно поместить копию этого ключа в систему и использовать эту переменную, чтобы разблокировать ее и добавить к агенту.
- Сценарий развертывания для вашего проекта извлечет код вашего проекта git, а затем проверит наличие агента GPG. Если агент загружен, он может попытаться расшифровать проверку.
В случае персонального компьютера разработчика это найдет их ключ, в случае автоматически созданных компьютеров - ключ развертывания. В любом случае вы можете управлять доступом к секретам в среде развертывания, как еще один разработчик проекта.
Какой бы инструмент вы не использовали для создания машин, он отвечает за хранение и внедрение секретов, вероятно, в виде файла с секретным ключом и парольной фразы в переменной среды, которая используется для загрузки файла ключа в агент.