Kubernetes 密钥的最佳实践

在 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 管理的其他 ServiceAccount 注释

您还可以在 ServiceAccount 上使用 kubernetes.io/enforce-mountable-secrets 注释来强制执行有关如何在 Pod 中使用 Secret 的特定规则。有关更多详细信息，请参阅有关此注释的文档。

改进 etcd 管理策略

请考虑在不再使用 etcd 使用的持久存储后将其擦除或销毁。

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

配置对外部 Secret 的访问

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

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

开发人员

本节为开发人员提供了一些良好实践，以便在构建和部署 Kubernetes 资源时提高机密数据的安全性。

将 Secret 访问权限限制为特定容器

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

读取后保护 Secret 数据

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

避免共享 Secret 清单

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