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 Secret Store CSI Driver 是一个 DaemonSet，它允许 kubelet 从外部存储中检索 Secret，并将 Secret 作为卷挂载到你授权访问数据的特定 Pod 中。

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

使用交换内存的最佳实践

有关为 Linux 节点设置交换内存的最佳实践，请参阅交换内存管理。

开发者

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

限制 Secret 访问到特定容器

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

读取后保护 Secret 数据

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

避免共享 Secret 清单

如果你通过清单配置 Secret，并以 base64 编码 Secret 数据，那么共享此文件或将其签入源代码仓库意味着所有能够读取该清单的人都可以访问该 Secret。