PROJECT_ID env 和 Secret Manager 访问答案

【问题标题】：PROJECT_ID env and Secret Manager AccessPROJECT_ID env 和 Secret Manager 访问
【发布时间】：2021-06-06 05:14:23
【问题描述】：

我想在云构建步骤中使用 Secret Manager 将凭证存储到我们的工件。我使用类似于以下内容的构建来工作：

steps:
- name: 'busybox:glibc'
  entrypoint: 'sh'
  args: ['-c', 'env']
  secretEnv: ['SECRET_VALUE']
availableSecrets:
  secretManager:
  - versionName: "projects/PROJECT_ID/secrets/TEST-SECRET/versions/1"
    env: 'SECRET_VALUE'

一切都很好，没有问题 - 然后我尝试稍微改进一下：

steps:
- name: 'busybox:glibc'
  entrypoint: 'sh'
  args: ['-c', 'env']
  secretEnv: ['SECRET_VALUE']
availableSecrets:
  secretManager:
  - versionName: "projects/$PROJECT_ID/secrets/TEST-SECRET/versions/1"
    env: 'SECRET_VALUE'

但随后它会引发错误： ERROR: (gcloud.builds.submit) INVALID_ARGUMENT: failed to get secret name from secret version "projects/$PROJECT_ID/secrets/TEST-SECRET/versions/1"

我已经能够添加 TRIGGER 级别的环境变量 (SECRET_MANAGER_PROJECT_ID)，并且效果很好。唯一的问题是触发环境，它在重建时不可用，这会破坏很多东西。

有谁知道如何在不使用触发器参数的情况下从 CloudBuild 中获取 Secret Manager 的 PROJECT_ID？

【问题讨论】：

你试过- versionName: projects/${PROJECT_ID}/secrets/TEST-SECRET/versions/1吗（我也认为如果有用的话，你可以使用versions/lastest而不是特定版本）
是的，我也试过了：ERROR: (gcloud.builds.submit) INVALID_ARGUMENT: failed to get secret name from secret version "projects/${PROJECT_ID}/secrets/TEST-SECRET/versions/1 感觉就像一个非常烦人的边缘案例。
在“Cloud Build”设置下，您是否启用了“Secret Manager Accessor”？（或关注these instructions？）
目前不支持。
如果有人想知道，我没有批准甚至查看推荐编辑所需的代表！

标签： google-cloud-build google-secret-manager

【解决方案1】：

目前，无法在 secret 字段中设置动态值。我已将此反馈直接提供给 Google Cloud PM，已考虑在内，但我没有更多信息可分享，尤其是可用性方面。

【讨论】：

【解决方案2】：

请改用$PROJECT_NUMBER。

https://cloud.google.com/build/docs/configuring-builds/substitute-variable-values#using_default_substitutions

【讨论】：

【解决方案3】：

Cloud Build 现在似乎允许在构建配置的 availableSecrets 字段中使用替换变量。

来自 Google Cloud 的documentation on using secrets：

在所有构建步骤之后，添加一个 availableSecrets 字段以指定要用于您的密钥的密钥版本和环境变量。 您可以在 secretVersion 字段的值中包含替换变量。您可以在构建中指定多个密钥。

我能够在自己的构建配置中使用$PROJECT_ID 变量，如下所示：

...
availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/api-key/versions/latest
      env: API_KEY

诚然，上面引用的文档与推荐的 configuration file schema 之间似乎（至少目前）存在一些差异。在文档中，他们引用了secretVersion，但似乎已更改为versionName。无论哪种情况，它似乎都能正常工作。

【讨论】：