关于将GKE Secrets迁移至Secret Manager的迁移指南咨询

目前没有谷歌官方发布的单份覆盖全流程的标准化迁移指南，相关迁移的最佳实践分散在两个产品的官方文档模块中，结合生产环境实操经验整理的可直接落地的全流程迁移步骤完全符合官方规范要求：

• 前置准备
  先给执行迁移操作的主体配齐权限：需要同时持有目标GKE集群的Secret读取权限、对应项目下Secret Manager的密钥创建/版本管理权限；提前在目标项目开通Secret Manager服务，给GKE工作负载配置好Workload Identity打通权限链路，避免后续业务访问Secret Manager时出现鉴权失败。
• 存量GKE Secrets导出
  用kubectl命令批量导出指定命名空间下的自定义Secret，注意过滤掉K8s自动生成的服务账号令牌这类不需要迁移的系统资源：

  # 导出指定命名空间下非系统类的Secret资源
  kubectl get secrets -n <替换为你的业务命名空间> -o json | jq '.items[] | select(.type != "kubernetes.io/service-account-token")' > gke_secrets_export.json
  

  导出完成后必须人工校验文件内容，确认密钥值、关联标签没有遗漏，也没有混入不需要迁移的系统凭证。
• 密钥批量导入Secret Manager
  写简单的遍历脚本读取导出的Secret文件，把每个密钥键值对逐一创建为Secret Manager中的独立密钥，导入时根据业务要求配置好密钥的地域复制策略、权限标签、自动轮换规则、过期时间：

  安全提示：导入过程中禁止把密钥明文打印到运行日志，避免敏感信息泄露；所有密钥导入完成后，要逐一抽样校验密钥值和原GKE Secret中的内容完全一致，避免导入错漏。

• 工作负载适配改造
  根据业务实际情况选适配方案，不需要强行修改业务代码：
  • 对不方便改代码的存量老业务，直接用GKE原生支持的Secret Manager存储驱动，把Secret Manager里的密钥以原生Volume的形式挂载到Pod内，和原来挂载GKE Secret的使用体验完全一致，业务代码零改动
  • 对新业务或者可改造的业务，直接在代码逻辑里调用Secret Manager接口拉取密钥，就能用上细粒度权限控制、访问审计、自动密钥轮换这些原生能力
• 切流验证与旧资源清理
  先在测试环境跑通全链路验证，再按业务模块灰度切流到Secret Manager的密钥源，观察1-2个完整业务周期没有出现密钥拉取失败、值不匹配的问题后，再定时清理GKE集群里存储的旧Secret资源，完成全量迁移。

• 避坑提醒：
  迁移全程做好密钥备份，绝对不要在没完成切流验证的情况下提前删除原有GKE Secret；多集群多环境的迁移建议按测试、预发、生产的顺序逐步推进，不要一次性全量操作引发生产故障。

内容的提问来源于stack exchange，提问作者Vyacheslav Gorbov