Kubernetes Secret 的良好实践

在 Kubernetes 中，Secret 是一种存储敏感信息的对象，例如密码、OAuth 令牌和 SSH 密钥。

Secret 让你可以更好地控制敏感信息的使用方式，并降低意外暴露的风险。Secret 值被编码为 Base64 字符串，默认情况下存储时未加密，但可以配置为静态加密。

一个Pod 可以通过多种方式引用 Secret，例如作为卷挂载或环境变量。Secret 用于存放机密数据，而 ConfigMap 用于存放非机密数据。

以下最佳实践适用于集群管理员和应用开发者。使用这些指南来提高 Secret 对象中敏感信息的安全性，并更有效地管理 Secret。

集群管理员

本节提供集群管理员可以用来提高集群中机密信息安全性的最佳实践。

配置静态加密

默认情况下，Secret 对象在 etcd 中未加密存储。你应该在 etcd 中配置对 Secret 数据的加密。有关说明，请参阅对 Secret 数据的静态加密。

配置对 Secret 的最小权限访问

规划你的访问控制机制时，例如 Kubernetes 基于角色的访问控制 (RBAC)，请考虑以下有关访问 Secret 对象的指南。你也应该遵循RBAC 最佳实践中的其他指南。

• 组件：将 watch 或 list 访问权限仅限制给最高权限的系统级组件。仅当组件的正常行为需要时，才授予对 Secret 的 get 访问权限。
• 人类用户：限制对 Secret 的 get、watch 或 list 访问权限。仅允许集群管理员访问 etcd。这包括只读访问。对于更复杂的访问控制，例如限制访问带有特定注解的 Secret，请考虑使用第三方授权机制。

能够创建使用 Secret 的 Pod 的用户也可以看到该 Secret 的值。即使集群策略不允许用户直接读取 Secret，同一个用户也可能有权运行一个 Pod，然后该 Pod 会暴露 Secret。你可以检测或限制拥有此类访问权限的用户有意或无意暴露 Secret 数据所造成的影响。一些建议包括：

• 使用短期有效的 Secret
• 实施审计规则，对特定事件发出警报，例如单个用户同时读取多个 Secret

限制对 Secret 的访问

使用独立的命名空间来隔离对挂载的 Secret 的访问。

改进 etcd 管理策略

考虑在 etcd 使用的持久存储不再使用后，擦除或粉碎其内容。

如果有多个 etcd 实例，请配置实例之间加密的 SSL/TLS 通信，以保护传输中的 Secret 数据。

配置访问外部 Secret

你可以使用第三方 Secret 存储提供商将你的机密数据保存在集群外部，然后配置 Pod 访问这些信息。Kubernetes Secrets Store CSI Driver 是一个 DaemonSet，它允许 kubelet 从外部存储检索 Secret，并将这些 Secret 作为卷挂载到你授权访问数据的特定 Pod 中。

有关支持的提供商列表，请参阅 Secrets Store CSI Driver 的提供商。

开发者

本节提供开发者在构建和部署 Kubernetes 资源时用来提高机密数据安全性的最佳实践。

将 Secret 访问限制到特定容器

如果在一个 Pod 中定义了多个容器，并且只有其中一个容器需要访问某个 Secret，则请配置卷挂载或环境变量，以使其他容器无法访问该 Secret。

读取后保护 Secret 数据

应用在从环境变量或卷读取机密信息后，仍然需要保护其值。例如，你的应用必须避免以明文方式记录 Secret 数据或将其传输给不可信的第三方。

避免共享 Secret Manifest

如果你通过一个manifest 配置 Secret，并且 Secret 数据已编码为 Base64，那么共享此文件或将其提交到源代码仓库意味着能够读取该 manifest 的所有人都可以访问该 Secret。