Otomi-core项目：从Hashicorp Vault迁移到SealedSecrets的技术方案

在Kubernetes生态系统中，密钥管理一直是安全架构中的关键环节。随着技术演进，许多团队开始从传统的Hashicorp Vault解决方案转向更轻量级的SealedSecrets方案。本文将深入分析在otomi-core项目中实现这一迁移的技术细节。

迁移背景与挑战

传统的密钥管理方案Hashicorp Vault虽然功能强大，但在某些场景下显得过于复杂。SealedSecrets作为Kubernetes原生的解决方案，通过非对称加密机制，允许将加密后的密钥直接存储在版本控制系统中，大大简化了密钥管理流程。

迁移过程中面临的主要技术挑战包括：

1. 密钥类型差异：原有Vault生成的密钥类型为Opaque，而SealedSecrets使用kubernetes.io/opaque类型
2. 所有权转移：需要正确处理密钥的ownerReferences字段变更
3. 零停机迁移：确保应用在迁移过程中不受影响

迁移技术方案详解

核心迁移流程

1. 数据提取阶段：

   • 遍历每个团队命名空间下的所有密钥
   • 读取现有密钥的完整数据内容
   • 对敏感数据进行Base64解码获取原始值

2. 密钥转换阶段：

   • 使用集群的SealedSecrets控制器公钥加密数据
   • 生成符合规范的SealedSecret自定义资源定义
   • 保留原有密钥的所有关键元数据

3. 安全替换阶段：

   • 首先部署新生成的SealedSecret资源
   • 验证SealedSecret控制器已成功生成解密后的密钥
   • 删除原有的ExternalSecret资源和关联的密钥
   • 清理values仓库中的ExternalSecret定义

关键技术实现细节

对于不可变(immutable)密钥的特殊处理：

# 迁移前的密钥定义示例
apiVersion: v1
kind: Secret
metadata:
  annotations:
    reconcile.external-secrets.io/data-hash: 50d16d92ef5cd5ead6d8a286435b6727
  name: demo-secret
  ownerReferences:
  - apiVersion: external-secrets.io/v1beta1
    kind: ExternalSecret
    name: demo-secret

# 迁移后的密钥定义示例
apiVersion: v1
kind: Secret
metadata:
  name: demo-secret
  ownerReferences:
  - apiVersion: bitnami.com/v1alpha1
    kind: SealedSecret
    name: demo-secret
type: kubernetes.io/opaque

迁移验证要点

1. 数据一致性检查：确保迁移前后密钥的data字段内容完全一致
2. 权限验证：确认应用Pod仍能正常访问迁移后的密钥
3. 所有权验证：检查ownerReferences是否已正确更新为SealedSecret控制器
4. 类型验证：确认密钥类型已正确转换为kubernetes.io/opaque

最佳实践建议

1. 分批次迁移：建议按团队或业务重要性分批迁移，降低风险
2. 备份策略：迁移前确保完整备份原有Vault中的密钥数据
3. 监控观察：迁移后密切监控应用行为，特别是依赖密钥的敏感服务
4. 文档更新：同步更新团队文档，反映新的密钥管理流程

总结

从Hashicorp Vault迁移到SealedSecrets不仅是工具的更换，更是密钥管理理念的转变。通过本文描述的迁移方案，团队可以在保证业务连续性的前提下，享受到更简单、更云原生的密钥管理体验。这种迁移不仅降低了系统复杂度，还提高了密钥管理的安全性和可审计性。