Mozilla sops with KMS和Git被低估(2019年)

当我开始使用Kubernetes和Infrastructure as Code时，我很快发现我需要一个秘密管理解决方案，但当我在谷歌上搜索时，似乎并没有就一种可以普遍适用于所有情况的最佳实践方法达成坚实的共识。因此，今年早些时候，我为自己设定了一个目标，要发现现有的应用程序和基础设施机密管理解决方案，提出我认为最好的解决方案，并培养对它的实际掌握。在追寻的同时。

大多数人对云知识管理系统是什么或做什么缺乏技术和通俗的理解。

这些人没有意识到，虽然在过去没有安全的方式在Git中存储加密的秘密，但从那时起，加密技术已经发展起来，现在可以在Git中安全地存储加密的秘密，这要归功于AWS KMS、Azure KeyVault或GCP KMS等云提供商KMS解决方案。

Vault的大部分炒作是有根据的，因为几十年来一直没有好的秘密管理解决方案，然后是Terraform制造商的Vault，它具有内置的秘密轮换，随着时间的推移进行积极维护，拥有出色的文档、支持和社区，并且Vault是唯一符合我对理想秘密管理解决方案的要求的*解决方案。我说保险库被夸大了，因为我经常看到它被推荐为治疗所有应该适用于所有人的黄金标准…。

通过REST API或独立于平台的CLI二进制文件与任何技术堆栈完美集成。(如果它与Terraform、Ansible、Kubernetes和CICD管道顺利集成，则可获得额外奖励)。

面向未来的大型社区或长期维护的历史(我不想要废弃软件，除非它可能是永恒的/功能完整的废弃软件，如Unix Utilities)。

真正安全(我应该能够让任何安全负责人相信它是防弹的，足以通过安全审计。)。

支持粒度ACL+开发人员机密创建自助服务选项项目级隔离：项目A的运营人员不应该看到项目B的生产机密。

版本化的机密(可协助过渡和自动化、部署、回滚和支持技术债务方案，其中机密和配置交织在配置文件和数据库连接字符串中。)。

*注：Mozilla sops也符合我的要求，但我当时并没有意识到这一点，因为我原本以为做git加密的秘密没有安全的方法。

许多工具涉及将解密密钥存储在用户的主目录或密钥环中，这导致加密数据和密钥在同一台机器上。

在这种情况下，泄露的解密密钥在统计上是不可避免的(漏洞乘以repo的克隆数乘以时间)。

不可能撤销泄露的解密密钥。如果您担心解密密钥可能已经被泄露，但它被泄露的可能性很低，那么由于git的分布式历史记录，撤销密钥是不可行的。即使您可以清除GIT服务器的历史记录，并使用新的加密密钥重新加密所有秘密，仍将存在可以使用旧密钥解密的repo的历史克隆。

如果怀疑有妥协的可能，唯一可行的对策是轮换所有的证书，这是一项昂贵的操作，管理层通常不愿凭直觉放弃。

一些git加密工具是步枪解决方案：运行命令解密机密，然后在将其推送到repo之前忘记加密。

每当我找到秘密管理解决方案时，我都会注意到我可以将其分为4个主要类别：

具体到单一的技术堆栈(Ansible、Chef、Puppet、Salt、Jenkins)(我出于2和5个原因而不考虑这些)。

使用您自己的Secrets Management Service(有几个潜在可行的选项，但是每个选项都引入了它自己的复杂性，所以专注于一个是有意义的。Hashicorp的Vault显然是赢家，因为它有许多功能、文档、大型社区以及长期支持和开发的记录。)。

完成分析后，我花了一个月的空闲时间在用于存储静态机密的Vault服务器上工作，以帮助我掌握Vault的工作原理，我希望它安全、易于维护和易于使用。为此，我尽了最大努力启用TLS，将Vault配置、角色、策略和Kubernetes Infrastructure作为高可用性Vault/Consul集群的代码添加到GIT资源库中，使用KMS自动解封，编写良好的自述文档，启用版本化的键值存储，.。

金库仍然需要一个地方来储存它的秘密。(Vault将其基础设施作为代码机密存储在哪里？KMS自动解封的HTTPS证书和IAM密码)。

保险库在很多方面都很昂贵。(您必须支付基础设施和存储费用。这还不够简单，你可以从头开始设置它，编写一份自述文件，并在一小时内培训几个人如何使用它，使用基础设施作为代码和预制的自述文件