Sealed Secrets 是什么
GitOps 流程里 Secret 不能明文入库，Sealed Secrets 的解法是「用集群公钥加密」：kubeseal 用控制器公钥把 Secret 加密成 SealedSecret 资源，密文可以安全提交进 Git；控制器在集群内用私钥解密还原为普通 Secret。默认作用域绑定命名空间加名称，密文被复制到其他命名空间或改名后无法解开，防止密文被搬用。私钥只存在集群里，备份与恢复演练是运维的责任。
基本信息
| 流程 | kubeseal 用控制器公钥加密 → 提交 SealedSecret → 集群解密为 Secret |
|---|---|
| 作用域 | 默认 strict 绑定命名空间+名称；可配置 namespace-wide 或 cluster-wide 放宽 |
| 密钥 | 控制器私钥在集群内，备份私钥并防止泄露与轮换丢失 |
| 适用 | 单集群小规模封装；跨集群大规模常配合外部密钥库使用 |
典型使用场景
- GitOps 仓库提交密钥：密文可入库，Argo 等控制器同步后由集群自动解密。
- 交付制品带配置：把目标集群的公钥用来加密，密文随部署清单一起交付。
- 变更审计：密文进 Git 历史，谁在什么时候改了哪个密钥可追溯。
- 灾备恢复：备份控制器私钥，集群重建后原有密文仍可解密。
- 临时演练：用测试集群公钥加密样本数据，安全验证流水线。
加密示例
加密示例
kubectl create secret generic db --from-literal=password='...' --dry-run=client -o yaml |
kubeseal --format yaml > sealed-db.yaml
kubectl apply -f sealed-db.yaml
# 默认 strict 作用域：绑定命名空间+名称
# --scope namespace-wide / cluster-wide 按需放宽（放宽=密文可复用范围变大）作用域对比
| scope | 绑定 | 风险 |
|---|---|---|
| strict（默认） | 名称+命名空间 | 最低，改名/换命名空间即失效 |
| namespace-wide | 整个命名空间 | 密文可在同命名空间内改名复用 |
| cluster-wide | 整个集群 | 复用范围最大，慎用 |
SealedSecret 适合小规模封装；跨集群与大规模场景常配合外部密钥库使用，避免每集群一套密钥图谱。
控制器支持密封密钥轮换，但存量密文不会自动重加密：轮换后按计划用 kubeseal 重新加密旧密文，避免旧密钥长期留在控制器里。