Kubernetes 如何配置 Secret 安全管理敏感数据

Secret 并非加密机制，仅 Base64 编码存入 etcd，安全依赖 RBAC、etcd 静态加密和最小化分发；需选对类型（Opaque/tls/dockerconfigjson）、匹配创建方式（命令行/YAML）、合理挂载（环境变量或 tmpfs 卷），并结合 helm-secrets 等工具加固。

Secret 本身不是加密机制，它只是把敏感数据做 Base64 编码后存进 etcd，默认并不加密。真正安全靠的是三层防护：RBAC 权限控制、etcd 静态加密配置、以及最小化分发（只给需要的 Pod 所在节点下发）。用对类型、配好权限、结合外部工具（如 helm-secrets），才能构建实际可用的安全链。

选对 Secret 类型，避免“挂错钥匙”

Secret 类型决定 Kubernetes 组件能否正确识别和使用内容：

1. Opaque：最通用，适合密码、API 密钥等任意键值对；用 kubectl create secret generic 或 YAML 的 type: Opaque 创建
2. kubernetes.io/tls：专用于 TLS 证书，必须含 tls.crt 和 tls.key 两个 key；Ingress 只认这个类型，用 kubectl create secret tls 创建
3. kubernetes.io/dockerconfigjson：私有镜像仓库认证专用；必须用 kubectl create secret docker-registry，否则 Kubelet 拉镜像会失败
4. kubernetes.io/service-account-token：禁止手动创建，由 Kubernetes 自动签发短期 Token（1.24+ 版本）

创建方式要匹配使用场景

命令行适合快速验证或 CI/CD 脚本中生成临时 Secret；YAML 文件更适合纳入 Git 管理（但注意：明文内容仍需额外保护）：

1. 从文件创建（如证书、密钥）：kubectl create secret generic app-tls --from-file=tls.crt --from-file=tls.key
2. 从字面量创建（如数据库密码）：kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password='P@ssw0rd!'（特殊字符记得加单引号）
3. 用 YAML 创建时，data 字段的值必须是 Base64 编码结果，不能直接写明文；可用 echo -n "value" | base64 快速编码

挂载或注入，按需选择访问方式

Pod 使用 Secret 有两种主流方式，安全性与灵活性各有侧重：

1. 作为环境变量注入：适合少量键值，如数据库用户名/密码；但要注意：环境变量可能被进程快照或日志意外捕获
2. 以 Volume 挂载为文件：更推荐，尤其对证书、密钥类二进制数据；挂载路径默认是 /var/run/secrets/kubernetes.io/serviceaccount（ServiceAccount）或自定义路径；文件系统是 tmpfs，不落盘，内存中销毁
3. 挂载时可指定 mode: 0400 控制文件权限，避免被容器内其他进程读取

别止步于 Secret：配合外部工具加固流程

仅靠原生 Secret 不足以满足合规或团队协作要求。生产环境建议叠加以下实践：

1. 启用 etcd 静态加密：在 kube-apiserver 启动参数中配置 --encryption-provider-config，让 Secret 在磁盘上也保持密文
2. 用 helm-secrets 管理 Helm Chart 中的敏感 values：把加密后的 secrets.yaml 提交到 Git，CI 流水线用 SOPS/Age/KMS 解密后部署，实现“加密即代码”
3. 严格限制 RBAC：为 Secret 创建专用 Role，只允许特定 ServiceAccount 或用户 get、list，禁用 watch 和 update（除非必要）