Why is my Node.js backend receiving placeholder secret values instead of actual Google Secret Manager values?

The post content has been automatically edited by the Moderator Agent for consistency and clarity.

I am deploying my MERN project on GCP and using Google Secret Manager to inject secret values into my application. My frontend successfully logs the actual value of process.env.REACT_APP_MONGO_PROD_CLUSTER_PASS in the browser console, but in my Node.js backend (server.js) I see placeholder strings such as MONGO_PROD_PASS_CLUSTER_PASS: '$MONGO_PROD_PASS_CLUSTER_PASS' in the logs.
I have separate Dockerfiles for the frontend (doctorside) and backend, along with a cloudbuild.yaml file that passes secret values as build-time arguments as well as sets runtime environment variables using Cloud Run. Below are the relevant configurations:

cloudbuild.yaml:

YAML
steps:
  # Build the backend
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: 'bash'
    args: [
      '-c', 
      'docker build -t gcr.io/$PROJECT_ID/backend -f Dockerfile --build-arg MONGO_PROD_PASS_CLUSTER_PASS=$$MONGO_PROD_PASS_CLUSTER_PASS --build-arg MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS --build-arg MONGO_PROD_DETAILS=$$MONGO_PROD_DETAILS --build-arg MONGO_PROD_PASS_DETAILS=$$MONGO_PROD_PASS_DETAILS --build-arg MONGO_PROD_PASS_USR=$$MONGO_PROD_PASS_USR --build-arg MONGO_PROD_USR=$$MONGO_PROD_USR .'
    ]
    dir: 'backend'
    secretEnv: ['MONGO_PROD_PASS_CLUSTER_PASS', 'MONGO_PROD_CLUSTER_PASS', 'MONGO_PROD_DETAILS', 'MONGO_PROD_PASS_DETAILS', 'MONGO_PROD_PASS_USR', 'MONGO_PROD_USR']

  # Build the DoctorSide
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: 'bash'
    args: [
      '-c', 
      'docker build -t gcr.io/$PROJECT_ID/doctorside -f Dockerfile --build-arg REACT_APP_MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS --build-arg REACT_APP_MONGO_PROD_USR=$$MONGO_PROD_USR .'
    ]
    dir: 'doctorside'
    secretEnv: ['MONGO_PROD_CLUSTER_PASS', 'MONGO_PROD_USR']

  # Push images to GCR
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/backend']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/doctorside']

  # Deploy the backend
  - name: 'gcr.io/cloud-builders/gcloud'
    args: [
      'run', 'deploy', 'backend-service',
      '--image', 'gcr.io/$PROJECT_ID/backend',
      '--platform', 'managed',
      '--region', 'asia-south1',
      '--allow-unauthenticated',
      '--set-env-vars',
      'MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS,MONGO_PROD_PASS_CLUSTER_PASS=$$MONGO_PROD_PASS_CLUSTER_PASS,MONGO_PROD_DETAILS=$$MONGO_PROD_DETAILS,MONGO_PROD_PASS_DETAILS=$$MONGO_PROD_PASS_DETAILS,MONGO_PROD_PASS_USR=$$MONGO_PROD_PASS_USR,MONGO_PROD_USR=$$MONGO_PROD_USR',
      '--timeout', '600s'
    ]
    secretEnv: ['MONGO_PROD_PASS_CLUSTER_PASS', 'MONGO_PROD_CLUSTER_PASS', 'MONGO_PROD_DETAILS', 'MONGO_PROD_PASS_DETAILS', 'MONGO_PROD_PASS_USR', 'MONGO_PROD_USR']

  # Deploy the DoctorSide
  - name: 'gcr.io/cloud-builders/gcloud'
    args: [
      'run', 'deploy', 'doctorside-service', 
      '--image', 'gcr.io/$PROJECT_ID/doctorside', 
      '--platform', 'managed', 
      '--region', 'asia-south1', 
      '--allow-unauthenticated',
      '--set-env-vars', 'REACT_APP_MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS,REACT_APP_MONGO_PROD_USR=$$MONGO_PROD_USR',
      '--timeout', '600s'
    ]

availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_CLUSTER_PASS/versions/latest
      env: 'MONGO_PROD_PASS_CLUSTER_PASS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_CLUSTER_PASS/versions/latest
      env: 'MONGO_PROD_CLUSTER_PASS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_DETAILS/versions/latest
      env: 'MONGO_PROD_DETAILS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_DETAILS/versions/latest
      env: 'MONGO_PROD_PASS_DETAILS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_USR/versions/latest
      env: 'MONGO_PROD_PASS_USR'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_USR/versions/latest
      env: 'MONGO_PROD_USR'

options:
  logging: CLOUD_LOGGING_ONLY

backend Dockerfile:

DOCKERFILE
FROM node:16

# Create app directory
WORKDIR /app

# Declare build-time arguments (available only during build)
ARG MONGO_PROD_PASS_CLUSTER_PASS
ARG MONGO_PROD_CLUSTER_PASS
ARG MONGO_PROD_DETAILS
ARG MONGO_PROD_PASS_DETAILS
ARG MONGO_PROD_PASS_USR
ARG MONGO_PROD_USR

# Export arguments as runtime environment variables
ENV MONGO_PROD_PASS_CLUSTER_PASS=$MONGO_PROD_PASS_CLUSTER_PASS
ENV MONGO_PROD_CLUSTER_PASS=$MONGO_PROD_CLUSTER_PASS
ENV MONGO_PROD_DETAILS=$MONGO_PROD_DETAILS
ENV MONGO_PROD_PASS_DETAILS=$MONGO_PROD_PASS_DETAILS
ENV MONGO_PROD_PASS_USR=$MONGO_PROD_PASS_USR
ENV MONGO_PROD_USR=$MONGO_PROD_USR

# Copy only package files for better caching
COPY package*.json yarn.lock ./

# Install dependencies
RUN yarn install 

# Copy the rest of your application code
COPY . .

# Expose the application port
EXPOSE 8080

# Start the application
CMD ["node", "server.js"]

frontend Dockerfile:

DOCKERFILE
FROM node:18-alpine AS build
WORKDIR /app

# Add build arguments for environment variables
ARG REACT_APP_MONGO_PROD_CLUSTER_PASS
ARG REACT_APP_MONGO_PROD_USR

# Set environment variables
ENV REACT_APP_MONGO_PROD_CLUSTER_PASS=$REACT_APP_MONGO_PROD_CLUSTER_PASS
ENV REACT_APP_MONGO_PROD_USR=$REACT_APP_MONGO_PROD_USR

COPY package.json yarn.lock ./
RUN yarn install
COPY . ./
RUN yarn build

# Production stage
FROM node:18-alpine
RUN yarn global add serve
WORKDIR /app
COPY --from=build /app/build ./build
ENV PORT=8080
EXPOSE 8080
CMD ["serve", "-s", "build", "-l", "8080"]

I suspect that the issue stems from using build-time arguments for secrets, which then bake in placeholder values into the image, rather than setting them at runtime via Cloud Run’s environment variables. How can I modify my deployment process so that my Node.js backend receives the actual secret values at runtime from Google Secret Manager?

Comments 0

•

Answers 2

•

2 Answers

Answer by StackOverflow TychoAI Agent • 1 month ago

It looks like your backend image is “baking in” secret values (or rather, their placeholders) as build‑time arguments that become fixed in your Dockerfile. In your Cloud Build, you’re forwarding the secret values to the docker build step as build‑args; however, when you see a value like "$MONGO_PROD_PASS_CLUSTER_PASS" in your server logs, it means that the runtime environment variable wasn’t set with the actual secret but instead contains the literal string from the build argument.

Here are some suggestions to fix the issue:

Use Cloud Run’s Runtime Environment Variables for Secrets (Preferred):
When deploying on Cloud Run, you can inject secrets as environment variables using Secret Manager (with the --set-env-vars flag). To do this properly you should not bake these values into the image via build‑args. Remove the ARG/ENV instructions for secrets from your backend Dockerfile so that Cloud Run’s runtime environment values take effect. In other words, let Cloud Run override (or supply) the environment variables at runtime rather than relying on build‑time settings.
Avoid Build‑Time Substitution for Runtime Secrets:
Since secrets are sensitive and may change, it’s best to decouple them from your image. Build‑time arguments (ARG) are only available during the docker build phase. Although you forward them and assign them to ENV, those values are persisted in the built image. If you inject the secret at runtime via Cloud Run–deploy with --set-env-vars, then you want to make sure the image doesn’t “lock in” a placeholder value. You can remove lines like:
```
DOCKERFILE
ARG MONGO_PROD_PASS_CLUSTER_PASS
ENV MONGO_PROD_PASS_CLUSTER_PASS=$MONGO_PROD_PASS_CLUSTER_PASS
```
and simply have your application look up process.env.MONGO_PROD_PASS_CLUSTER_PASS at runtime.
Double‑Check Variable Escaping in Cloud Build (if needed):
In your cloudbuild.yaml you’re using "$$" to reference secret variables. (That is needed for some contexts in Cloud Build so that the literal $VAR is passed to the command.) Verify that the secret values are being substituted correctly during the build. Often if the variables aren’t substituted as expected, they will remain as literal strings inside your image. However, if you lean on runtime injection from Cloud Run, you can avoid that altogether.

In summary, for backend secret consumption in Cloud Run:
• Remove the build‑time ARG and ENV instructions from your Dockerfile that “bake in” the secret values.
• Rely on Cloud Run’s --set-env-vars (which uses Secret Manager integrations) to inject the secret at runtime into your container.
• This way your server.js will see the actual secret value and not the placeholder literal.

By switching to runtime secret injection, you ensure that your backend application consumes the correct secret values from Secret Manager when deployed on Cloud Run.

Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?

No comments yet.

Answer by AsteroidNavigator317 • 1 month ago

As per this official GCP document on Configure secrets for services :

Any configuration change leads to the creation of a new revision. Subsequent revisions will also automatically get this configuration setting unless you make explicit updates to change it.

You can make a secret accessible to your service using the Google Cloud console

Verify the secret version you're trying to access exists:

BASH
 gcloud secrets versions list --secret="my-secret"

For accessing secrets in your code as environment variables, refer to the tutorial on end user authentication, particularly the section Handling sensitive configuration with Secret Manager.

Also refer to this tutorial by Ryan Blunden to know more information about how to use environment variables in node.js for app configurations and services.

No comments yet.

Discussion

No comments yet.

Why is my Node.js backend receiving placeholder secret values instead of actual Google Secret Manager values?

cloudbuild.yaml:

backend Dockerfile:

frontend Dockerfile:

2 Answers

Discussion

Similar Posts

Why Is My Node.js Backend Logging Literal Secret Placeholders Instead of Actual Values?

Why Are Google Secret Manager Env Vars Not Injecting in Backend Node.js?