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

Question

I'm currently delivering a node + nestjs application via as a docker container using Google's Cloud Run.

I'm using the secrets manager for the secrets & using projects for dev/staging/prod and I'm trying to make the secrets available to my container in the cloud.

Current process is triggered by "yarn docker:auth" which triggers a series of bash scripts:

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

The arguments/flags on the last command also doesn't work and I'm prompted to pick a platform & region every time I run it.

I've tried adding the flags to my auth.yaml file as well as the secrets as exemplified in the documentation for Google Cloud Build but it fails every time due to syntax error.

In the yaml file, I added the following at the bottom of the yaml file nested under no property:

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

My questions is:

• Is it possible to do this via YAML at all?

I've also added a startup function to my nodejs app that tries to use @google-cloud/secret-manager from npmjs to load the secrets into environment. I've got no issues doing this locally using the default credentials, but:

• Will the docker container inside Cloud run have any kind of "Default" credentials? and If not, what would be the best way to inject it? It seems bad practice to either build or ship the container with a service account key-file.

The fundamental issue I'm trying to solve is getting those secrets into the container environment.

Thank you.

EDIT:

Wanted to add the YAML part where I am assigning the service account to the cloud run container:

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

But sadly this still results in this generic error:

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

With absolutely no further details within the logs themselves, blank, The container doesn't start locally due to no service account injected into it, but without that piece of code that handles the secrets-loading. the container starts locally just fine.

Answer 1

There's a bit to unpack here. In short, I think you might be confusing build time with runtime secrets and how they are accessed.

If you do not need access to secrets in your compilation or test phases, you can omit the availableSecrets stanza from your cloudbuild.yaml . That pulls in secrets at build time . For example, suppose you wanted to run your tests in Cloud Build, and you needed an API key or database password to execute the tests. That's when you'd use theCloud Build + Secret Manager integration .

---

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

If you are using gcloud locally, you shouldn't need a service account. You can authenticate to gcloud as yourself via:

gcloud auth login && gcloud auth application-default login

You generally perform these steps once, as part of installing gcloud. The same is true for configure-docker . You generally only run this command once

---

The Cloud Run + Secret Manager integration is currently in preview. You can request access using this Google Form . (For future readers, if that form no longer exists, it means the integration is public and no signup is required.)

---

Will the docker container inside Cloud run have any kind of "Default" credentials? and If not, what would be the best way to inject it? It seems bad practice to either build or ship the container with a service account key-file.

Yes, the Cloud Run container will execute as the default Compute Engine service account by default. This service account has broad permissions, but it does not have permission to access secrets.

We recommend that you create a new service account specific for this workload and grant access to only the specific secrets it needs . Then, you can run the Cloud Run container using your custom service account with the --service-account flag:

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

---

The arguments/flags on the last command also doesn't work and I'm prompted to pick a platform & region every time I run it.

We'd need to see the full command to understand what's failing, specifically what is the ... .

---

With absolutely no further details within the logs themselves, blank, The container doesn't start locally due to no service account injected into it, but without that piece of code that handles the secrets-loading. the container starts locally just fine.

You can view the logs for the container in Cloud Logging from the sidebar.