Secrets是Kubernetes中一种对象类型，用来保存密码、私钥、口令等敏感信息。那么在Kubernetes中，如何实现对Secrets的有效管理，以保障这些机密数据的安全呢？
Kubernetes内置的Secrets管理
Kubernetes提供了一种内置机制，用于存储用户希望保密的配置值。 它们可以对特定名称空间进行访问控制，默认情况下，它们的内容不会显示在kubectl get或 describe 输出中。 它们是base64编码的，因此即使直接从 kubectl 中提取内容，内容也不会立即显现。
这些 secrets 以 plaintext 形式存储在集群的etcd服务器上，除非将etcd配置为使用TLS加密通信，否则当etcd集群同步时，这些机密在线上可见。 此外，拥有或可以获得集群中任何节点的root访问权限的任何人，都可以通过模拟 kubelet 来读取所有机密数据。
因此，除非您的安全要求非常低，否则建议使用第三方解决方案来保护机密数据。
来自第三方的Secrets管理器
Kubernetes中有3种基本类别的Secrets管理解决方案，如果您的要求超出了内置Secrets功能设置的极低条件，您应该考虑这些类别：
来自云供应商的Secrets管理解决方案；
自己运行的开源解决方案，无论是在集群中还是在周围；
来自各种供应商的专有解决方案。
1、云管平台的Secrets商店
如果您在其中一个主要的公有云中运行，并且已经购买其Secrets管理服务，或者您只是想快速创建并且不考虑潜在的供应商锁定，那么云托管解决方案是一个不错的选择，比如AWS Secrets Manager。
2、开源的Secrets管理器
如果使用裸机，想要避免云供应商锁定，担心云供应商解决方案的安全性，或者需要与现有企业标准集成，您可能需要选择一个软件解决方案。
1）Vault
到目前为止，Kubernetes中使用最广泛，最受欢迎且功能最丰富的Secrets管理器是Vault。Vault比云管理的解决方案功能更丰富且能保持一致性，可与EKS，GKE，本地群集以及可能运行Kubernetes的任何位置完美配合。人们对基于Vault的云管理存储也存在争议，主要是由于很难设置和配置高性能的HA Vault集群，不过可以通过内置的自动化和支持来缓解。
它还提供了几个独特的功能：
完全私有的Cubbyholes，Token 令牌是唯一可以访问数据的人。
动态secrets。 Vault可以在数据库和云IAM中自动创建帐户和凭据。
PKI证书和SSH证书生成引擎，允许使用单个API调用生成和存储证书。
跨区域、跨云、跨数据中心复制，支持过滤器以限制不应跨群集传输的数据。
支持各种身份验证方法，并在需要时支持MFA。
2）Sealed Secrets
Kubernetes样式编排的一个好处是配置基于一组声明性json或yaml文件，可以很容易地存储在版本控制中，可以基于Git将操作变更自动化为单一事实。 这意味着，负载配置的每个更改都可以与应用程序代码进行相同的拉取请求和同行评审过程。
但是，像Vault这样的传统Secrets管理方法，以及上述所有云存储都为在Git之外管理的Secrets数据引入了第二个真实来源——在集群中引入了另一个完全独立跟踪的潜在变更/故障源。 这可能会使故障排除变得复杂，也会导致所有集群配置更改的审核日志记录变得复杂。
Sealed Secrets专为解决这一问题而设计。 它的工作原理是在Kubernetes集群中运行一个带有机密数据和公钥的控制器，并提供一个可以在标准配置文件中使用的加密字符串，并且只能由包含该私钥的控制器解密。
也就是说，可以将安全凭证直接存储在Git中的配置文件，和所有需要访问它的人共享Git存储库，但这些用户都不能访问这些凭据。这可用于创建基于GitOps的安全工作流。
网友评论