4

我目前正在使用 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 文件中，我在嵌套在 no 属性下的 yaml 文件底部添加了以下内容：

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

我的问题是：

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

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

  • 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.

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

4

1 回答 1

3

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

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

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 集成目前处于预览阶段。您可以使用此 Google 表单请求访问权限。（对于未来的读者，如果该表格不再存在，则意味着集成是公开的，无需注册。）

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

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

我们建议您为此工作负载创建一个特定的新服务帐户，并仅授予对它需要的特定机密的访问权限。然后，您可以使用带有以下--service-account标志的自定义服务帐号运行 Cloud Run 容器：

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

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

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

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

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

于 2021-03-09T17:34:28.797 回答