如何保障GCP App Engine app.yaml部署文件中环境变量安全

核心原则：不要将包含明文密码、密钥的配置提交到代码仓库，哪怕是私有仓库，也会因为人员权限变动、仓库泄露等问题带来敏感信息暴露风险，可通过以下几种落地方式解决：

• 方案1：使用云平台密钥管理服务存储敏感值（推荐）
  将DB_PASSWORD这类敏感信息统一存放到GCP Secret Manager服务中，给App Engine运行服务账号、CI流水线使用的服务账号分配对应密钥的读取权限。你不需要在提交到仓库的app.yaml中写入敏感值：既可以在服务代码启动时通过官方SDK拉取对应密钥加载到运行时环境，也可以在CI流水线的部署步骤中临时拉取密钥值，生成仅部署环节使用的临时完整配置文件，部署完成后自动销毁临时文件，全程不会有明文敏感值进入代码仓库。

• 方案2：CI流水线动态替换配置占位符
  提交到仓库的app.yaml中，敏感字段统一用变量占位符代替，示例配置如下：

  runtime: nodejs16 # or another supported version
  instance_class: F2
  env_variables:
    BUCKET_NAME: "example-gcs-bucket"
    DB_PASSWORD: "${DB_PASSWORD}"
  

  将DB_PASSWORD这类真实敏感值存入CI平台自带的加密变量存储中（Cloud Build、GitHub Actions、GitLab CI等主流CI/CD工具都提供该能力，普通仓库协作者无权限查看加密变量的明文值，仅流水线运行时可读取）。在部署执行前的预处理步骤中，通过envsubst、sed等工具将配置文件中的占位符替换为真实值，再执行App Engine部署命令即可，替换后的带明文配置仅存在于流水线临时运行环境，不会被提交回代码仓库。

• 方案3：拆分公共配置与敏感配置
  将不涉及敏感信息的公共配置（比如运行时版本、实例规格、非敏感环境变量）存放在仓库内的app.yaml中，敏感配置单独存放，将存放敏感配置的文件加入.gitignore规则，禁止提交到仓库。App Engine部署支持传入多个配置文件自动合并，本地调试时可以用本地保存的私有敏感配置文件，CI流水线部署时从加密存储中读取敏感值生成临时的敏感配置文件，和公共配置一同传入部署命令即可完成发布。

注意：不推荐将加密后的敏感值直接提交到仓库、再在流水线中解密使用的方案。这种方案一旦加密密钥泄露，仓库所有历史提交中的敏感内容都会被破解，且密钥轮换、值更新的维护成本很高，优先选择云厂商原生密钥管理服务或CI平台自带的加密变量能力。

内容的提问来源于stack exchange，提问作者Daniel Santos