git 凭据
我们都知道，我们不应该使用我们的代码向存储库提交任何密码或密钥（无论是公开的还是私有的）。 但是，可以在GitHub上找到成千上万个生产密码 （并且可能在公司内部存储库中找到成千上万个）。 有些人试图通过删除密码来解决此问题（一旦他们知道公开存储不是一个好主意），但是密码仍保留在git历史中。
知道不做什么是第一步，也是非常重要的一步。 但是我们如何存储生产凭证。 数据库凭证，系统秘密（例如，用于HMAC），用于第三方服务（如支付提供商或社交网络）的访问密钥。 似乎没有达成共识的解决方案 。
之前，我曾建议使用12因子的应用程序建议使用环境变量 –如果您可以使用一些环境变量 ，但是当变量数量增加时（就像在任何实际应用程序中一样），这将变得不切实际。 您可以通过bash脚本设置环境变量，但必须将其存储在某个地方。 实际上，即使是单独的环境变量也应存储在某个位置。
该位置可能是本地目录（风险），共享存储（例如访问受限的FTP或S3存储桶）或单独的git存储库。 我认为我更喜欢git存储库，因为它允许版本控制（注意：S3也可以，但是是特定于提供程序的）。 因此，您可以将所有特定于环境的属性文件及其所有凭据和特定于环境的配置存储在访问受限的git存储库中（仅Ops人员）。 只要它与源代码不是相同的存储库，那还不错。
这样的回购看起来像这样：
project
└─── production
| | application.properites
| | keystore.jks
└─── staging
| | application.properites
| | keystore.jks
└─── on-premise-client1
| | application.properites
| | keystore.jks
└─── on-premise-client2
| | application.properites
| | keystore.jks由于许多公司正在使用GitHub或BitBucket作为其存储库，因此将生产凭据存储在公共提供商上可能仍然存在风险。 因此，最好加密存储库中的文件。 一个好的方法是通过git-crypt 。 它是“透明”加密，因为它支持动态差异和加密以及解密。 设置完毕后，就可以继续处理该存储库，就像未加密一样。 甚至在Windows上都可以使用叉子 。
您只需运行git-crypt init （将git-crypt二进制文件放入OS路径后），即可生成密钥。 然后，指定.gitattributes，例如：
secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
*.properties filter=git-crypt diff=git-crypt
*.jks filter=git-crypt diff=git-crypt 这样就完成了。 好吧，差不多。 如果这是一个新鲜的仓库，那么一切都很好。 如果它是现有的存储库，则必须清除包含未加密文件的历史记录。 完成这些步骤后，您将获得一个附加的信息–在调用git commit之前，应调用git-crypt status -f以便对现有文件进行实际加密。
你几乎完成。 我们应该以某种方式共享和备份密钥。 对于共享部分，由2-3个Ops组成的团队共享同一密钥不是什么大问题，但是您也可以使用git-crypt的GPG选项（如README中所述）。 剩下的就是备份您的密钥（在.git / git-crypt目录中生成）。 您可以将其（受密码保护）存储在其他一些存储中，无论是公司共享文件夹，Dropbox / Google云端硬盘，甚至是您的电子邮件。 只要确保您的计算机不是唯一存在并且受保护的计算机即可。 我认为不需要旋转键，但是您可以设计一些旋转程序。
git-crypt的作者声称，在本来可以在公共仓库中加密几个文件的过程中，它表现出色。 并建议查看git-remote-gcrypt 。 但是，由于通常有特定于环境的配置的不敏感部分，您可能不想加密所有内容。 而且我认为即使在单独的回购方案中也可以使用git-crypt。 尽管加密是保护源代码存储库中凭据的一种好方法，但在同一存储库中配置环境配置仍然不一定是一个好主意。 特别是考虑到由不同的人/团队来管理这些凭据。 即使在小型公司中，也许并非所有成员都具有生产访问权限。
在这种情况下，尚待解决的问题是–如何将属性与代码更改同步。 有时，代码会添加应反映在环境配置中的新属性。 这里有两种情况–首先，属性可以随环境而变化，但是可以具有默认值（例如，计划的作业周期），其次，需要显式配置的属性（例如，数据库凭据）。 前者可以将默认值捆绑在代码存储库中，因此也可以捆绑在发布工件中，从而允许外部文件覆盖它们。 后者应通知进行部署的人员，以便他们可以设置适当的值。
具有版本化的特定于环境的配置的整个过程实际上非常简单且合乎逻辑，即使对图片添加了加密也是如此。 我认为这是我们应该遵循的良好安全实践。
翻译自: https://www.javacodegeeks.com/2018/06/storing-encrypted-credentials-git.html
git 凭据
转播
