借助Vault对接GCP Secret Manager实现F5 2NIC BIG-IP Terraform部署方案咨询

两种可选方案的优劣对比 #

方案1：Vault存储凭据 + Terraform自动创建GCP Secret Manager供给F5模块 #

• 优势
  • 改动量极低，无需修改原有F5模块的内部逻辑，避免后续模块版本升级时的代码合并冲突，适配性强
  • 全流程自动化：Terraform执行时自动从Vault拉取凭据、自动创建GCP Secret Manager密钥，完全消除手动操作步骤
  • 兼容性好，直接复用F5模块原生对接GCP Secret Manager的逻辑，无需额外调整F5实例的启动配置、网络规则
  • 权限边界清晰：仅需给Terraform执行账号授予Vault读取、GCP Secret Manager创建权限，F5实例仅保留GCP Secret Manager的对应密钥只读权限，无需额外配置F5对接Vault的身份校验规则
• 劣势
  • 凭据会在GCP Secret Manager额外存储一份，需要配套配置密钥权限收紧、自动过期策略，降低泄露风险

方案2：扩展F5模块直接对接Vault读取凭据 #

• 优势
  • 凭据仅在Vault统一存储，无多副本分散存储的风险，符合集中化凭据管理的安全合规要求
• 劣势
  • 需要大幅修改F5模块的初始化逻辑，包括给F5实例配置访问Vault的网络路由、身份认证规则、自定义凭据拉取脚本，后续F5模块版本更新时需要重新适配修改点，长期维护成本高
  • F5实例本身需要具备Vault访问权限，扩大了Vault的访问面，需要额外做细粒度权限隔离，避免越权访问其他敏感凭据

推荐技术方向 #

优先选择方案1，除非团队有明确的安全合规要求禁止凭据在Vault外存储：

• 落地效率高，仅需新增三部分Terraform代码即可实现需求：
  • 调用vault_generic_secret数据源从Vault读取F5管理员凭据
  • 调用google_secret_manager_secret、google_secret_manager_secret_version资源自动创建GCP Secret Manager密钥
  • 将生成的Secret ID直接传递给原有F5模块即可
• 稳定性强，完全兼容原有F5模块的成熟逻辑，不需要调整F5实例的运行配置，问题排查难度低

如果选择方案1，可补充以下优化配置：

• 给所有涉及凭据的Terraform资源/数据源添加sensitive = true标记，避免凭据明文输出到Terraform状态文件或执行日志中
• 给GCP Secret Manager的对应密钥配置最小访问权限，仅允许F5实例关联的服务账号读取该密钥
• 配置GCP Secret Manager密钥与Vault中对应凭据的同步轮转规则，降低长期固定凭据的泄露风险

内容的提问来源于stack exchange，提问作者Anand Rajagopal