Kubernetes Secrets 的最佳实践

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

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

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

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

集群管理员

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

配置静态加密

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

配置 Secret 的最小权限访问

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

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

能够创建使用 Secret 的 Pod 的用户也可以查看该 Secret 的值。即使集群策略不允许用户直接读取 Secret，但该用户也可能能够运行一个 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 中。

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

使用交换内存的最佳实践

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

开发人员

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

将 Secret 访问限制为特定容器

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

读取后保护 Secret 数据

应用程序仍然需要在从环境变量或卷读取后保护机密信息的价值。例如，您的应用程序必须避免以明文记录 Secret 数据或将其传输到不受信任的方。

避免共享 Secret 清单

如果您通过 清单 配置 Secret，并将 Secret 数据编码为 base64，则共享此文件或将其签入源代码存储库意味着 Secret 对任何可以读取该清单的人都可用。