在Kubernetes中管理秘密可能是一项繁琐的工作。在一个多服务多环境的设置中,你可能在不知不觉中拥有数百个秘密。很难跟踪所有的东西,同时管理秘密的轮换,加入新的服务,并以正确的访问权限加入新的人员。
有很多现有的解决方案来管理这些问题,如AWS Secret Manager和Vault。这些解决方案的功能通常远远超过我们在库存Kubernetes中的功能。而你的组织很有可能已经在使用这样的解决方案,他们对此很满意。因此,很多人认为,"为什么我不能在Kubernetes中使用这个?"
这导致了大量的项目,用于从云服务中同步秘密并将其注入Kubernetes秘密。
通过这篇博文,我们想向你展示这个领域的热门项目,并解释一个社区是如何在新的 外部秘密 项目上形成的 。
TL;DR:
- - - - 🧵👇- 日Repo链接:https://github.com/external-secrets/external-secrets
学校里最受欢迎的孩子
GoDaddy的 kubernetes-external-secrets (简称KES)是最受欢迎的外部秘密同步解决方案,在GitHub上有超过1700颗星,有大量的用户。这个解决方案很稳定,社区参与度很高,活跃的维护者经常推送改进。这个解决方案获得青睐的一个重要原因是,它可以很容易地扩展到支持任何你想使用的外部秘密供应商。
目前,它支持以下供应商:
- 阿里巴巴云秘密管理器
- Azure Key Vault
- 谷歌云秘密管理器
- IBM云秘密管理器
- AWS秘密管理器
- AWS系统管理器
- 和Hashicorp Vault
为了更深入地了解KES的工作原理,你可以看一下这篇博文,"Kubernetes外部秘密"。但简而言之,就像我们在这里描述的所有解决方案一样,它从外部供应商那里读取秘密,并将其同步到本地Kubernetes秘密中。
KES似乎是成为处理外部秘密的事实方式的完美候选者,考虑到它支持所有重要的供应商,拥有一个伟大的社区,并积极维护,对吗?但它有一个问题:它是用JavaScript开发的。
JavaScript本身并没有什么不好,但在这个用例中,使用Go有一些很大的优势。主要原因是Kubernetes中对Go的一流SDK支持。另一个原因是工具:使用Golang,我们可以利用 Kubebuilder 或 Operator SDK 来帮助我们启动和遵循Kubernetes Operator的最佳实践和标准。
其他的一些孩子
从事一个让你烦恼的问题,有趣的是,有时这个问题也会让很多其他人烦恼。但有时人们开始新的项目来解决他们的问题,而不是改进现有的项目。有时是因为有一个非常具体的要求,或者只是不知道有另一个目标相似的项目。我们想在本节中描述一些其他类似的项目。
Container Solutions External Secrets Operator
这个项目有182颗星,在 ArgoCD文档中提到了它 ,它是由 Riccardo M. Cefala创建的 ,因为Container Solutions内部有一个特殊的客户需求。它是用Go编写的,是可以作为新的中央解决方案的基础的候选人之一。它支持GCP SM、AWS SM、Credstash Gitlab CI变量和Azure密钥库。关于该项目的更多信息可以在项目的 Readme 上找到 。Container Solutions也在帮助启动新的中央工作,包括工程时间和借用基础设施,以实现e2e测试。
Itscontained Secret Manager
这个项目有36颗星,由 Kellin McAvoy 和 Nicholas St. Germain创建 。这个项目特别有意思,因为它是为了遵守新的共同 CRD讨论而创建的 (后面会有更多的介绍)。它支持AWS SM、GCP SM和Hashicorp Vault。它也是可能成为新的中央解决方案的基础的候选项目之一。更多关于这个项目的信息请看它的 Readme。
AWS Secret Operator
另一个比较受欢迎的项目,有220颗星,由 Yusuke Kuoka创建 。这个项目是特定于供应商的,只支持AWS,而不能扩展到其他供应商。这是一个更容易使用的选择,而且特定于供应商可以简化其代码。更多关于这个项目 的信息请见自述。这也是引发最初讨论的项目,我们将在下一节中讨论。
聚会
在上一节中,我们谈到了类似的项目是如何开始在周围出现的,在我们的案例中,我们注意到,当 这个问题 开始被其他类似的解决方案所填充。
一个因为 单个类似项目而产生的问题 开始扩展;很多其他项目基本上做同样的事情。列举几个(如果我们错过了提到你们中的某一个,很抱歉,请联系我们,我们可以在这里给予赞扬
😀: http