将 env 变量从 Google 的 Secret Manager 加载到在 Google Cloud Run 上运行但未通过 Cloud Build 部署的 Docker 容器中？

Question

我目前正在使用 Google 的 Cloud Run 作为 docker 容器交付 node + nestjs 应用程序。

我正在使用机密管理器来管理机密，并将项目用于开发/登台/生产，并且我正在尝试使机密可用于我在云中的容器。

当前进程由触发一系列 bash 脚本的“yarn docker:auth”触发：

docker build -t gcr.io/my_project_id_dev/auth-service -f .docker/auth.DockerFile . &&
gcloud auth activate-service-account abc@my_project_id_dev.iam.gserviceaccount.com --key-file=gcloud-sa.json &&
gcloud auth configure-docker &&
docker push gcr.io/my_project_id_dev/auth-service &&
gcloud beta run services replace .gcp/cloud_run/auth.yaml &&
gcloud run deploy auth ... --allow-unauthenticated  --platform managed --region europe-west2

最后一个命令的参数/标志也不起作用，每次运行时都会提示我选择平台和区域。

我已尝试将标志添加到我的 auth.yaml 文件以及 Google Cloud Build 文档中举例说明的秘密，但由于语法错误，每次都失败。

在yaml文件中，我在yaml文件的底部添加了以下内容，嵌套在no属性下：

availableSecrets:
  secretManager:
    - versionName: projects/my_project_id/secrets/mongo_uri/versions/latest
    env: 'mongo_uri'

我的问题是：

• 是否有可能通过 YAML 做到这一点？

我还在我的 nodejs 应用程序中添加了一个启动功能，它尝试使用来自 npmjs 的@google-cloud/secret-manager 将机密加载到环境中。使用默认凭据在本地执行此操作没有问题，但是：

• Cloud run 中的 docker 容器是否有任何类型的“默认”凭据？如果没有，注入它的最佳方法是什么？使用服务帐户密钥文件构建或发布容器似乎是一种不好的做法。

我试图解决的基本问题是将这些秘密放入容器环境中。

谢谢。

编辑：

想要添加我将服务帐户分配给云运行容器的 YAML 部分：

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: '2'
        run.googleapis.com/client-name: cloud-console
        run.googleapis.com/sandbox: gvisor
    spec:
      containerConcurrency: 2
      containers:
      - image:  gcr.io/my_project_id/auth-service
        ports:
        - containerPort: 3000
        resources:
          limits:
            cpu: 1000m
            memory: 512Mi
      serviceAccountName: abc@my_project_id.iam.gserviceaccount.com
      timeoutSeconds: 300

但遗憾的是，这仍然会导致这个一般错误：

(gcloud.beta.run.services.replace) Cloud Run error: Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

日志本身绝对没有更多细节，空白！由于没有注入服务帐户，容器不会在本地启动，但是如果没有处理秘密加载的那段代码，容器在本地启动就好了。

Answer 1

这里有一点需要解压。简而言之，我认为您可能会将 构建时间 与 运行时 机密以及它们的访问方式混淆。

如果您在编译或测试阶段不需要访问机密，则可以从 cloudbuild.yaml 中省略 availableSecrets 节。这会在构建时引入秘密。例如，假设您想在 Cloud Build 中运行测试，并且需要 API 密钥或数据库密码来执行测试。那时你会使用Cloud Build + Secret Manager integration。

---

gcloud auth activate-service-account abc@my_project_id_dev.iam.gserviceaccount.com --key-file=gcloud-sa.json

如果您在本地使用 gcloud，则不需要服务帐号。您可以通过以下方式对 gcloud 进行身份验证：

gcloud auth login && gcloud auth application-default login

作为安装 gcloud 的一部分，您通常会执行一次这些步骤。 configure-docker 也是如此。您通常只运行一次此命令

---

Cloud Run + Secret Manager 集成目前处于预览阶段。你可以request access using this Google Form。 （对于未来的读者，如果该表单不再存在，则意味着集成是公开的，无需注册。）

---

Cloud run 中的 docker 容器是否有任何类型的“默认”凭据？如果没有，注入它的最佳方法是什么？使用服务帐户密钥文件构建或发布容器似乎是一种不好的做法。

是的，默认情况下，Cloud Run 容器将作为默认的 Compute Engine 服务帐号执行。此服务帐户具有广泛的权限，但它没有有权访问机密。

我们建议您为此工作负载和grant access to only the specific secrets it needs 创建一个新的服务帐户。然后，您可以使用带有 --service-account 标志的自定义服务帐户运行 Cloud Run 容器：

gcloud run deploy auth --service-account "...@...iam.gserviceaccount.com"

---

最后一个命令的参数/标志也不起作用，每次运行时都会提示我选择平台和区域。

我们需要查看完整的命令以了解失败的原因，特别是 ... 是什么。

---

日志本身绝对没有更多细节，空白！由于没有注入服务帐户，容器不会在本地启动，但是如果没有处理秘密加载的那段代码，容器在本地启动就好了。

您可以从侧边栏中查看 Cloud Logging 中容器的日志。