0. 前言

在 Kubernetes 发展过程中，Secrets 一直是一个争议点：

• Kubernetes 原生 Secret 并不是真正意义上的“安全存储”
• Base64 不是加密，只是编码
• Secret 会出现在 etcd、节点内存、Pod 环境变量等多个位置
• 企业环境通常不会直接使用原生 Secret

因此围绕 Secret 管理，逐渐形成了几种主流方案。

1. Kubernetes 原生 Secret

最基础的方案。

apiVersion: v1
kind: Secret
metadata:
  name: db-secret

type: Opaque

data:
  password: cGFzc3dvcmQ=

Pod 中引用：

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

优点：

• Kubernetes 内置
• 配置简单
• 无额外组件

缺点：

• Base64 不是加密
• Secret 默认存储于 etcd（etc distribution 分布式配置）（etcd 是一个分布式、高可用的键值（Key-Value）存储系统，在 Kubernetes 中，etcd 是整个集群的核心数据存储，被称为 Kubernetes 的"大脑"或"注册表"）
• 运维人员容易获取
• GitOps 不方便管理

适合：

• 开发环境
• 测试环境
• 小型项目

---

2. etcd Encryption

Kubernetes 官方提供的静态加密方案。

开启后：

Secret
    ↓
API Server
    ↓ 加密
etcd

配置 EncryptionConfiguration：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration

resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-key>

优点：

• 官方支持
• 部署简单
• 防止直接读取 etcd

缺点：

• Key 仍需自行管理
• API Server 解密后依然明文
• 无法解决 Git 泄漏问题

适合：

• 所有生产环境

基本可以视为最低安全要求。

---

3. Sealed Secrets

基本介绍

由 Bitnami 提出。

核心思想：

Secret
    ↓
kubeseal
    ↓
SealedSecret
    ↓ Git

开发者：

kubeseal < secret.yaml > sealed-secret.yaml

生成：

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret

提交 Git：

Git
  ↓
ArgoCD
  ↓
Cluster
  ↓
Secret

优点：

• Git 中存储密文
• GitOps 友好
• 使用简单

缺点：

• 私钥保存在集群
• 集群迁移复杂
• 多集群管理麻烦

适合：

• ArgoCD（ArgoCD 是一个基于 GitOps 模式 的 Kubernetes 持续交付（CD）工具，主要用于自动化管理 Kubernetes 集群中的应用部署与配置同步，以 Git 为唯一可信源）
• Flux
• GitOps 场景

---

为什么需要 Sealed Secrets？

在传统的 Kubernetes 部署中，Secrets 是 base64 编码的，并不是加密的。如果直接将 Secret YAML 文件提交到 Git 仓库，任何有仓库访问权限的人都能看到敏感信息（如数据库密码、API 密钥等）。

Sealed Secrets 就是为了解决这个问题而设计的。

完整工作流程详解

1. 本地加密阶段（开发者操作）

# 1. 首先创建一个普通的 Secret 文件
cat > secret.yaml <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
data:
  password: $(echo -n "my-super-secret-password" | base64)
EOF

# 2. 使用 kubeseal 命令加密
kubeseal < secret.yaml > sealed-secret.yaml

关键点：

• kubeseal 会从 Kubernetes 集群获取公钥
• 用这个公钥加密 Secret 的内容
• 生成的 sealed-secret.yaml 可以安全地提交到 Git

生成的文件类似：

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: my-secret
  namespace: default
spec:
  encryptedData:
    password: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq...
  template:
    metadata:
      name: my-secret
      namespace: default

2. Git 存储阶段

sealed-secret.yaml → Git 仓库

安全性：

• Git 中只存储加密后的密文
• 没有私钥，任何人（包括 Git 仓库管理员）都无法解密
• 可以像普通代码一样进行代码审查、版本控制

3. 部署阶段（GitOps 工具）

Git 仓库
    ↓ (通过 ArgoCD/Flux 监控)
Kubernetes 集群
    ↓ (Sealed Secrets 控制器监听)
SealedSecret 资源

4. 解密阶段（集群内部）

SealedSecret 资源
    ↓ (集群内的 Sealed Secrets 控制器)
自动解密
    ↓
生成原始 Secret

核心机制：

• 集群中运行一个 Sealed Secrets 控制器
• 该控制器持有私钥（这个私钥永远不离开集群）
• 当检测到新的 SealedSecret 时，控制器用私钥解密
• 自动生成对应的 Kubernetes Secret

为什么这种设计是安全的？

安全边界划分

• 开发者机器：有公钥，可以加密，但无法解密
• Git 仓库：只有密文，没有任何解密能力
• Kubernetes 集群：持有私钥，可以解密，但私钥永不外泄

权限控制

• 开发者只需要权限创建 SealedSecret 资源
• 他们不需要直接访问 Secret 资源
• 集群管理员控制私钥的生命周期

与传统方法的对比

传统方式（不安全）：

Secret (明文base64) → Git → ArgoCD → Secret

❌ 问题：Git 中存储的是可逆的 base64 编码，等同于明文

Sealed Secrets 方式：

Secret → kubeseal (加密) → SealedSecret (密文) → Git → 集群 (解密) → Secret

✅ 优势：Git 中只有真正的加密数据，无法被解密

多集群管理问题

你提到的缺点确实存在：

问题场景：

• 每个集群有自己独立的密钥对
• 同一个 SealedSecret 不能在多个集群使用
• 集群迁移时，旧的 SealedSecret 无法在新集群解密

解决方案：

1. 使用相同密钥：在多个集群间同步私钥（有安全风险）
2. 范围策略：使用 --scope 参数指定作用范围

   kubeseal --scope cluster-wide < secret.yaml > sealed-secret.yaml
   

3. 命名空间管理：为每个环境（dev/staging/prod）使用不同的集群

实际使用示例

开发者日常流程：

# 1. 更新敏感配置
echo "new-password" | kubectl create secret generic db-secret \
  --dry-run=client --from-file=password=/dev/stdin -o yaml > secret.yaml

# 2. 加密
kubeseal --controller-name=sealed-secrets < secret.yaml > sealed-secret.yaml

# 3. 提交到 Git
git add sealed-secret.yaml
git commit -m "Update database password"
git push

为什么适合 GitOps？

1. 声明式配置：SealedSecret 是声明式的 Kubernetes 资源
2. 版本控制：所有变更都有 Git 历史记录
3. 自动化：ArgoCD/Flux 可以自动同步和部署
4. 审计追踪：谁在何时修改了什么密钥，一目了然
5. 环境一致性：不同环境使用相同的部署流程

总结

Sealed Secrets 的核心价值在于：将敏感数据的加密责任从人类转移到了系统。开发者不需要记住复杂的加密流程，只需要一个简单的命令；运维人员不需要担心 Git 仓库泄露导致的敏感信息泄露；安全团队可以确信私钥始终在受控的集群环境中。

虽然它有私钥管理、多集群支持等挑战，但在大多数中小型团队的 GitOps 实践中，它仍然是目前最实用、最安全的秘密管理方案之一。

4. External Secrets Operator (ESO)

近几年最流行的方案之一。

项目：External Secrets Operator

架构：

AWS Secrets Manager
HashiCorp Vault
Azure Key Vault
Google Secret Manager
       ↓
External Secrets Operator
       ↓
Kubernetes Secret

示例：

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret

spec:
  secretStoreRef:
    name: vault

  data:
    - secretKey: password
      remoteRef:
        key: prod/db/password

同步后：

Vault
   ↓
ESO
   ↓
Secret

优点：

• Secret 不进入 Git
• 支持多种 Secret Backend
• 云原生生态成熟
• GitOps 友好

缺点：

• Secret 最终仍会生成 K8s Secret
• 需要额外 Operator

适合：

• 大多数企业生产环境

目前很多团队已经把 ESO 作为默认方案。

---

5. HashiCorp Vault

业界最知名的 Secrets 管理平台。

HashiCorp Vault

架构：

Application
      ↓
Vault Agent
      ↓
Vault Server

Vault 可以：

• 存储 Secret
• 动态生成数据库账号
• 动态生成云账号
• 自动轮换密码

例如：

App
 ↓
请求 PostgreSQL 凭证
 ↓
Vault
 ↓
返回临时账号
 ↓
30分钟后自动失效

优点：

• 企业级
• 支持动态 Secret
• 完整审计日志
• 细粒度权限控制

缺点：

• 运维复杂
• 学习成本高
• 高可用部署较重

适合：

• 金融
• 大型企业
• 高安全场景

---

6. Vault Agent Injector

Vault 在 Kubernetes 中最经典的落地方式。

工作流程：

Pod 创建
   ↓
Admission Webhook
   ↓
注入 Vault Agent Sidecar
   ↓
从 Vault 拉取 Secret
   ↓
写入共享 Volume

Pod：

annotations:
  vault.hashicorp.com/agent-inject: "true"

最终：

Vault
 ↓
Agent
 ↓
tmpfs
 ↓
Application

优点：

• Secret 不经过 Git
• Secret 不写入 etcd
• 支持动态更新

缺点：

• 每个 Pod 多一个 Sidecar
• 资源开销较大

---

7. Secrets Store CSI Driver

Container Storage Interface（容器存储接口）

目前云厂商最推荐的方案之一。

项目：

Secrets Store CSI Driver

架构：

AWS Secrets Manager
Azure Key Vault
Vault
GCP Secret Manager
       ↓
CSI Driver
       ↓
Pod Volume

Pod：

volumeMounts:
- name: secrets-store

挂载后：

/mnt/secrets/password

优点：

• Secret 不进入 etcd
• 不创建 Kubernetes Secret
• 原生 CSI 生态
• 自动轮换支持较好

缺点：

• 应用需读取文件
• 兼容性依赖 Provider

适合：

• 云原生环境
• 安全要求较高场景

---

8. 云厂商托管方案

各大云基本都有自己的 Secret 服务：

云厂商	服务
Amazon Web Services	AWS Secrets Manager
Google Cloud	Google Secret Manager
Microsoft	Azure Key Vault
Alibaba Cloud	Alibaba Cloud KMS

通常配合：

• ESO
• CSI Driver

使用。

---

演进路线

很多团队都会经历类似路径：

阶段1
K8s Secret

阶段2
K8s Secret + etcd Encryption

阶段3
Sealed Secrets

阶段4
External Secrets Operator

阶段5
Vault / 云 Secret Manager

阶段6
Vault + CSI Driver
或
Cloud Secret Manager + CSI Driver

当前主流推荐

如果是 2026 年的新项目：

个人项目 / 小团队

K8s Secret
+
etcd Encryption

足够。

中大型企业

External Secrets Operator
+
AWS Secrets Manager

或者

External Secrets Operator
+
Vault

这是目前最常见的组合。

高安全要求

Vault
+
Secrets Store CSI Driver

这样 Secret 可以做到：

Git 中没有
etcd 中没有
镜像中没有

仅在 Pod 运行期间以内存文件形式存在，是 Kubernetes Secret 管理体系中安全性较高的一种实现方式。