管理kubernetes秘密

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (13)

我们从Kubernetes开始,并想知道其他项目如何管理Kubernetes的秘密:

  • 由于Kubernetes的秘密值只是base64编码,因此不建议将秘密提交到源代码控制中
  • 如果不承诺源代码控制,它应该保存在其他地方的某个中心位置,否则没有单一的事实来源。如果它存储在其他一些地方(例如Hashicorp Vault),如何与CI集成?CI是否从Vault获取值,在Kubernetes中按需创建机密资源?
  • 另一种方法可能是拥有一个专门的团队来处理基础设施,只有该团队知道并管理秘密。但如果项目数量很大,这个团队可能会成为瓶颈
提问于
用户回答回答于

我使用k8秘密作为保存秘密的商店。当我定义一个秘密时,我在k8中定义它而不是在其他地方,然后弄清楚如何将它注入k8。我有一个方便的客户端来创建查找和修改我的秘密。我不需要担心离开防火墙的秘密。它们很容易注入我的服务中

如果你想要一个额外的保护层,你可以用KMS或类似的东西自己加密k8中的秘密

用户回答回答于

其他项目如何管理Kubernetes的秘密

由于它们不是(至少还没有)正确的秘密(base64编码),我们将它们视为分离受限访问git存储库。

我们的大多数项目都有代码存储库(包含非秘密相关清单,例如部署和服务作为CI / CD管道的一部分)和单独的清单存储库(保存名称空间,共享数据库内容,秘密以及或多或少的任何一个 - time init与CI / CD分开,需要额外的权限才能实现,或者应该以任何其他方式限制,例如秘密。

话虽如此,虽然常规开发人员无法访问受限制的存储库,但必须特别注意CI / CD管道,因为即使您保密,在CI / CD阶段它们也是已知的(并且可以显示/滥用) ,那可能是那里的弱安全点。我们通过让我们的一个DevOps监督和批准(受保护的分支机构)对CI / CD管道的任何更改来缓解这种情况,就像高级主管监督要部署到生产环境的代码更改一样。

请注意,这在很大程度上取决于项目数量和人员配置,以及安全/开发压力/基础设施集成方面的实际项目需求。

扫码关注云+社区

领取腾讯云代金券