K8s Secret 资源是存储 JWT 签名密钥的标准方式，支持通过环境变量或数据卷挂载注入 Pod。高安全场景建议配合 External Secrets Operator 对接 Vault 等外部凭据管理，避免密钥在 etcd 明文存储。
先说结论：使用 K8s Secret 存储密钥，通过 volumeMount 挂载文件读取优于环境变量注入，可降低进程环境泄漏风险。
- 先判断：确认集群是否开启 etcd 静态加密，未开启时敏感密钥建议走外部凭据管理。
- 优先做：创建 Opaque 类型 Secret，采用 volumeMount 方式挂载到容器指定路径。
- 再验证：进入 Pod 检查文件内容是否可读，确认应用启动日志无鉴权失败报错。
命令速用版
通过 kubectl 命令快速创建 Secret 并在 Deployment 中引用，适用于测试环境或快速验证场景。
# 创建 Secret（值需 Base64 编码）
kubectl create secret generic jwt-secret `--from-literal`=JWT_SECRET=my-signing-key
# Deployment 引用片段
env:
- name: JWT_SECRET
valueFrom:
secretKeyRef:
name: jwt-secret
key: JWT_SECRET为什么会这样
Secret 对象将敏感信息与容器镜像解耦，避免硬编码导致的数据泄露风险。K8s Secret 默认采用 Base64 编码存储，虽非加密但能防止配置文件明文暴露，配合 RBAC 权限控制可有效降低泄露概率。
分步处理
按创建资源、配置挂载、应用部署的顺序执行，每步需检查资源状态。
1. 创建 Secret 资源
使用 kubectl create 或 yaml 文件定义，数据字段 value 需 Base64 编码。生产环境建议通过 CI/CD 流水线自动创建，避免人工操作留痕。
2. 配置 Pod 注入方式
环境变量方式适合简单应用，数据卷挂载方式适合需读取文件的应用。挂载路径建议设为只读权限，限制容器内进程修改。
3. 应用部署与更新
提交 Deployment 配置后，观察 Pod 状态是否为 Running。密钥轮换时需更新 Secret 内容并滚动重启 Pod，确保新密钥生效。
怎么验证是否生效
通过进入容器检查环境变量或文件内容，结合应用日志确认鉴权功能正常。
# 检查环境变量
kubectl exec -it <pod-name> -- env | grep JWT_SECRET
# 检查挂载文件
cat /etc/secrets/jwt-signing-key
# 查看应用日志
kubectl logs <pod-name> | grep -i "auth\|jwt"常见坑
Base64 编码不是加密，etcd 默认明文存储 Secret 数据，RBAC 权限配置不当会导致集群内任意 Pod 读取密钥。环境变量注入可能被进程列表泄露，高安全需求场景应选用数据卷挂载并配合外部凭据管理工具实现自动轮换。
常见问题
Secret 的 Base64 编码安全吗？
Base64 只是编码而非加密，任何有 kubectl get secret 权限的人都能解码获取明文。
如何做到密钥不停机轮换？
使用 External Secrets Operator 对接 Vault 等服务，实现密钥自动注入与透明轮转，服务零重启。
环境变量和数据卷挂载哪个更安全？
数据卷挂载更安全，应用读取文件路径可规避进程环境变量泄漏风险，适合高安全场景。
参考来源
- 从本地开发到 K8s 集群:Seedance 2.0 Node.js 部署的 5 层安全加固策略 (含 JWT 密钥注入防护与 SDK 沙箱隔离方案)
- tymon/jwt-auth 与云原生应用集成:K8s 认证
- Kubernetes Secret 不安全？External Secrets Operator 接入凭据管理服务实战，自动轮转零停机
- 【Kubernetes Secret 安全配置指南：从创建配置到环境变量、数据卷使用及私有镜像仓库实践】-CSDN 博客
- kubernetes 存储篇 —— Secret
- 创建密钥
- Kubernetes`--secret` 的简介和使用
- Kubernetes 配置管理与密钥管理最佳实践:ConfigMap 与 Secret 使用场景、Pod 配置注入方法与安全防护指南
- 第 02 篇:K8s 存储与配置管理:ConfigMap、Secret、PV/PVC 实战——Java SaaS 多租户配置最佳实践-CSDN 博客