security - Git-crypt 工作流程 - 部署到多个服务器或 Circleci/travisci

Question

尝试了解基于 git-crypt 的保密解决方案的完整工作流程。

该工具本身在开发机器上运行得非常好，甚至扩展到多个开发人员似乎也能正常工作。

但是，我不清楚当部署到云上的多个服务器时，这将如何工作，有些服务器是按需创建的:

1. 在新服务器上无人值守创建 GPG key 的挑战(需要有人创建密码，或者它位于源代码管理中，然后，这一切有什么值(value)？)

   <

2. 创建 GPG 后，如何将其添加到环中？

3. 假设我们决定跳过#1，只在服务器之间共享 key ，那么密码短语作为“git-crypt 解锁”过程的一部分是如何提供的？

我确实尝试过搜索，但找不到一个好的端到端工作流程。

Answer 1

与许多 Linux 工具一样， git-crypt 这是一个只做一件事并把它做好的例子。 This philosophy规定任何一个实用程序都不会尝试提供一整套工具或生态系统，而只是提供一个可以按照您喜欢的方式与其他功能链接的功能。在这种情况下git-crypt不将自己标榜为部署工具，也不具有任何特定的集成到工作流程中。它的工作只是允许 git 存储库存储可在某些结帐中使用但不能在其他结帐中使用的敏感数据。用例可能会有所不同，您如何将其与其他工具链接起来也可能会有所不同。

根据您问题的措辞，我还想澄清 git-crypt不是“保密解决方案”。事实上，它根本不保守你的 secret ，它只是让你可以在你保存 secret 的地方随意移动。在这种情况下，它使您能够将 secret 数据与非 secret 信息一起保存在存储库中，但这样做的代价是将保密负担转移到另一个工具上。它将一个 secret 交换为另一个 secret :您项目的版本控制 secret 组件换取 GPG key 。如何管理 secret 仍然取决于您，但现在您需要处理的 secret 是 GPG key 。

保守 secret 仍然取决于您。对于您和其他开发人员来说，这可能意味着在您的主目录中存在一个 GPG 私钥文件，希望在分配给其他程序(如 git-crypt)之前通过输入到代理中的密码来保护该文件。这需要它。

在能够自动将软件部署到服务器的情况下，必须信任某处的某些东西并拥有真正的 secret 。这通常是顶级工具，例如 Ansible或Puppet ，或者可能是像 Gitlab 这样的 CI 环境, Travis ，或Circle 。通常，除了您的顶级部署工具之外，您不会信任任何东西，因为它知道何时在环境中注入(inject) secret ，何时不注入(inject)(或者在开发/暂存/生产环境中，要注入(inject)哪些 secret )。

我不熟悉 Circle，但我知道 Travis 在您的项目设置选项卡下有一个环境变量部分，您可以使用它来将私有(private)信息传递到虚拟机。有some documentation了解如何使用它。 Gitlab 内置的 CI 系统有 something similar ，并且可以传递不同的 secret 来测试与部署环境等。

我建议您的工作流程最可能的用例是:

• 创建一个用于生产计算机的特殊 secret 变量，其中包含仅用于部署的 GPG key 的密码。无论您使用什么来创建机器，都应该将此 key 的副本放入系统中，并使用此变量来解锁它并将其添加到代理中。
• 您的项目的部署脚本将检查您的 git 项目代码，然后检查 GPG 代理。如果加载了代理，它可以尝试解密结账。

如果是开发人员的个人计算机，它将找到他们的 key ，如果是自动创建的计算机，它将找到部署 key 。无论哪种方式，您都可以像项目中的另一位开发人员一样管理对部署环境中 secret 的访问。

无论您使用什么工具来创建机器，都将负责保存和注入(inject) secret ，可能以私钥文件和环境变量中的密码短语的形式，用于将 key 文件加载到代理中。