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

在Kubernetes生态系统中，Secrets管理一直是安全实践的重要组成部分。许多团队最初选择使用Hashicorp Vault作为集中式的Secrets管理解决方案，但随着云原生技术的发展，SealedSecrets因其更简单的操作模型和与Kubernetes的深度集成而受到青睐。

迁移背景

SealedSecrets是Bitnami开发的一个开源项目，它允许用户将加密后的Secret存储在版本控制系统中，只有集群内的控制器才能解密。这与Hashicorp Vault的集中式管理模型形成对比，后者需要额外的运维复杂性和网络访问。

迁移的主要动机是为用户提供更简单的Secrets管理体验，同时确保现有工作负载不受影响。这种迁移特别适合那些希望减少外部依赖、简化架构的团队。

技术挑战

在迁移过程中，我们面临几个关键技术挑战：

1. Secret类型差异：传统Secret类型为Opaque，而SealedSecrets创建的是kubernetes.io/opaque类型
2. 所有权转移：需要将Secret的所有权从ExternalSecret控制器转移到SealedSecret控制器
3. 零停机迁移：必须确保迁移过程中应用不会因Secret不可用而中断

迁移方案详解

迁移流程

1. 数据提取阶段：

   • 遍历每个团队命名空间中的所有Secret
   • 读取现有Secret的内容和元数据
   • 对Secret数据进行加密，生成SealedSecret资源定义

2. 资源替换阶段：

   • 删除原有的ExternalSecret资源
   • 删除对应的Kubernetes Secret资源
   • 应用新创建的SealedSecret资源

3. 验证阶段：

   • 确认SealedSecret控制器成功重建了Secret
   • 验证应用能够正常访问新创建的Secret
   • 清理values仓库中的ExternalSecret定义

关键技术点

所有权转移是通过修改Secret的ownerReferences字段实现的。迁移后，Secret将由SealedSecret控制器管理，而不是原来的ExternalSecret控制器。

对于不可变Secret，由于无法直接修改，我们采用先删除后重建的策略。这种策略虽然简单，但需要确保应用能够容忍短暂的Secret不可用。

实施建议

1. 分批次迁移：建议按团队或按应用逐步迁移，而不是一次性迁移所有Secret
2. 监控验证：迁移后密切监控应用行为，确保没有因Secret变化导致的问题
3. 回滚计划：准备好回滚方案，在出现问题时能够快速恢复
4. 文档更新：更新团队文档，反映新的Secrets管理流程

总结

从Hashicorp Vault迁移到SealedSecrets可以简化Kubernetes环境中的Secrets管理，减少外部依赖。虽然迁移过程需要考虑Secret类型和所有权等技术细节，但通过合理的规划和执行，可以实现平滑过渡。这种迁移特别适合那些希望采用更云原生方式管理敏感数据的团队。

未来，随着Kubernetes原生Secrets管理能力的增强，我们可能会看到更多团队采用类似SealedSecrets的解决方案，在保持安全性的同时简化运维复杂度。