在 Kubernetes 中，Secret 是一个用于存储敏感信息（如密码、OAuth 令牌和 SSH 密钥）的对象。Secret 允许用户对如何使用敏感信息进行更多的控制，并减少信息意外暴露的风险。默认情况下，Secret 值被编码为 base64 字符串并以非加密的形式存储，但可以配置为静态加密（Encrypt at rest）。
Pod 可以通过多种方式引用 Secret，例如在卷挂载中引用或作为环境变量引用。Secret 设计用于机密数据，而 ConfigMap 设计用于非机密数据。
以下是集群管理员和应用开发者应遵循的良好实践：
- 使用适当的 Secret 对象类型来存储不同类型的敏感信息；
- 不要将多个 Secret 对象组合成一个，以避免管理和维护困难；
- 避免在 Secret 对象中存储不必要的敏感信息；
- 定期审查和更新 Secret 对象，以确保它们仍然安全且有用；
- 使用标签和注释来组织和管理 Secret 对象；
- 使用命名约定来标识 Secret 对象的内容和用途；
- 使用 TLS 证书时，请确保正确配置和更新 Secret 对象。
一、集群管理员
接下来介绍了集群管理员可用于提高集群中机密信息安全性的良好实践。
1、配置静态加密
默认情况下，Secret 对象以非加密的形式存储在 etcd 中， 配置对在 etcd 中存储的 Secret 数据进行加密。
2、配置 Secret 资源的最小特权访问
在规划 Kubernetes 基于角色的访问控制 (RBAC) 这类访问控制机制时，需要注意以下指导信息：
- 组件级别：限制最高特权的系统级组件可以执行 watch 或 list 访问。仅在组件的正常行为需要时才授予对 Secret 的 get 访问权限。
- 人员级别：限制对 Secret 的 get、watch 或 list 访问权限。仅允许集群管理员访问 etcd。这包括只读访问。对于更复杂的访问控制，例如使用特定注解限制对 Secret 的访问，请考虑使用第三方鉴权机制。
注意：授予对 Secret 的 list 访问权限将意味着允许对应主体获取 Secret 的内容。
如果一个用户可以创建使用某 Secret 的 Pod，则该用户也可以看到该 Secret 的值。即使集群策略不允许用户直接读取 Secret，同一用户也可能有权限运行 Pod 进而暴露该 Secret。因此，可以检测或限制具有此访问权限的用户有意或无意地暴露 Secret 数据所造成的影响。
建议：
- 使用生命期短暂的 Secret，以减少潜在的安全风险；
- 实现对特定事件发出警报的审计规则，例如同一用户并发读取多个 Secret 时发出警报。
3、改进 etcd 管理策略
不再使用 etcd 所使用的持久存储时，考虑擦除或粉碎这些数据。但是如果存在多个 etcd 实例，则在实例之间配置加密的 SSL/TLS 通信以保护传输中的 Secret 数据。
4、配置对外部 Secret 的访问权限
可以使用第三方 Secret 存储提供商将机密数据保存在集群之外，然后配置 Pod 访问该信息。Kubernetes Secret 存储 CSI 驱动是一个 DaemonSet， 它允许 kubelet 从外部存储中检索 Secret，并将 Secret 作为卷挂载到特定的、授权访问数据的 Pod。
二、开发者
接下来为开发者提供了构建和部署 Kubernetes 资源时用于改进机密数据安全性的良好实践。
1、限制特定容器集合才能访问 Secret
如果在一个 Pod 中定义了多个容器，且仅其中一个容器需要访问 Secret，则可以定义卷挂载或环境变量配置， 这样其他容器就不会有访问该 Secret 的权限。
2、读取后保护 Secret 数据
应用程序从一个环境变量或一个卷读取机密信息的值后仍然需要保护这些值。 例如，应用程序必须避免以明文记录 Secret 数据，还必须避免将这些数据传输给不受信任的一方。
3、避免共享 Secret 清单
如果通过清单（Manifest）配置 Secret， 同时将该 Secret 数据编码为 base64， 那么共享此文件或将其检入一个源代码仓库就意味着有权读取该清单的所有人都能使用该 Secret。
注意：Base64 编码不是一种加密方法，它没有为纯文本提供额外的保密机制。
