一、为什么需要专门管理敏感信息？

想象一下这样的场景：你开发了一个需要连接数据库的微服务，如果把数据库密码直接写在代码里，就如同把家门钥匙挂在门口——所有路过的人都能轻易拿到。在 Kubernetes 集群中，敏感信息（密码、API Token、证书）的泄露可能导致整个系统被攻击，而 Secrets 正是 Kubernetes 为解决这一问题设计的核心组件。

二、Kubernetes Secrets 基础

定义：Secret 是 Kubernetes 中存储敏感数据的对象，以键值对（Key-Value）形式保存。
特点：

  • 默认以 Base64 编码存储（非加密！）
  • 支持挂载到 Pod 作为文件或环境变量
  • 细粒度的权限控制（RBAC）

三、实战示例：手动创建并使用 Secrets

技术栈：原生 Kubernetes 命令行工具（kubectl）
以下示例展示如何创建 Secret 并注入到 Pod 中。

echo -n 'admin123' | base64  # 输出 "YWRtaW4xMjM="

# 步骤2：定义 Secret 对象
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=    # "admin" 的 Base64
  password: YWRtaW4xMjM= # "admin123" 的 Base64

# 步骤3：将 Secret 挂载到 Pod 的 /etc/secrets 目录
apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: creds
      mountPath: "/etc/secrets"
      readOnly: true
  volumes:
  - name: creds
    secret:
      secretName: db-credentials

注释说明：

  1. type: Opaque 表示自定义类型，适合存储通用密钥。
  2. 挂载后，/etc/secrets 目录会生成 username 和 password 两个文件。
  3. 安全警告：Base64 是可逆编码，等同于明文存储，需配合加密方案使用（后文详解）。

四、进阶加密方案：让 Secrets 真正安全

方案1：启用 Kubernetes Etcd 加密

原理：在 Etcd 层面对 Secrets 进行 AES-CBC 或 AES-GCM 加密。
操作步骤：

# 创建加密配置文件 encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <32字节随机密钥，如通过 head -c 32 /dev/urandom | base64 生成>
      - identity: {} # 保留未加密数据的兼容性

启动 API Server 时指定配置：
kube-apiserver --encryption-provider-config=encryption-config.yaml ...

方案2：使用 Sealed Secrets（推荐用于 GitOps）

技术栈：Bitnami Sealed Secrets 控制器
核心逻辑：通过公钥加密 Secret，仅目标集群的私钥可解密。

# 步骤1：安装控制器（以 Helm 为例）
helm install sealed-secrets bitnami/sealed-secrets

# 步骤2：加密本地 Secret 定义文件
kubectl create secret generic db-creds --dry-run=client --from-literal=pass=123 -o json | kubeseal -o yaml > sealed-secret.yaml

# 步骤3：应用密封后的 Secret（可安全提交到 Git）
kubectl apply -f sealed-secret.yaml

五、应用场景深度分析

场景 技术选型建议 风险规避策略
数据库密码 Etcd 加密 + RBAC 定期轮换密钥
CI/CD Token Sealed Secrets + 审计日志 限制 Namespace 访问权限
TLS 证书 Cert-Manager 自动管理 禁用证书文件全局读取权限

六、技术优缺点对比

方案 优点 缺点
原生 Secrets 开箱即用，简单易上手 Base64 编码非加密，依赖 Etcd 安全性
Etcd 加密 原生支持，透明化加密 密钥管理复杂，需自行备份
Sealed Secrets 完美适配 GitOps 流程 需额外部署控制器，学习成本略高
外部 Vault 集成 集中化管理，动态凭证 架构复杂度大幅增加

七、你必须知道的注意事项

  1. 最小权限原则：通过 RBAC 限制 Secrets 的 get/list 权限。
  2. 传输安全：确保 kubectl port-forward 或 Dashboard 访问使用 HTTPS。
  3. 生命周期管理：定期轮换密钥（如结合 Argo CD 自动同步）。
  4. 审计日志：开启 Kubernetes Audit Logs 监控敏感操作。

八、总结

Kubernetes Secrets 是敏感信息管理的第一道防线，但默认配置远未达到生产级安全要求。通过结合 Etcd 加密、Sealed Secrets 等方案，才能构建多层防御体系。记住：安全没有银弹，只有持续评估和改进才能应对不断变化的威胁环境。