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

JAR*_*ans 5 security deployment gnupg continuous-deployment git-crypt

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

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

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

  1. 在新服务器上无人值守创建 GPG 密钥的挑战(需要有人创建密码,或者它位于源代码管理中,那么,这一切有什么价值?)

  2. 创建 GPG 后,如何将其添加到环中?

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

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

Cal*_*leb 2

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

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

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

在能够自动将软件部署到服务器的情况下,必须信任某个地方的真实秘密。这通常是AnsiblePuppet等顶级工具,或者可能是GitlabTravisCircle等 CI 环境。通常,除了您的顶级部署工具知道何时在环境中注入秘密以及何时不注入(或者在开发/暂存/生产环境中,要注入哪些秘密)之外,您不会信任任何东西。

我不熟悉 Circle,但我知道 Travis 在你的项目设置选项卡下有一个环境变量部分,你可以用它来将私有信息传递到虚拟机中。有一些文档介绍如何使用它。Gitlab 的 CI 系统构建有类似的东西,并且可以传递不同的秘密来测试与部署环境等。

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

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

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

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