Passing secretEnv to kaniko cloud build

[anthonyWalter]

Actual behavior

steps:
    # Build and push using kaniko cache
    - name: "gcr.io/kaniko-project/executor:latest"
      args:
          - --destination=gcr.io/$PROJECT_ID/community-image
          - --cache=true
          - --build-arg=CONTENTFUL_CONTENT_DELIVERY_API_KEY=$$CONTENTFUL_CONTENT_DELIVERY_API_KEY
          - --build-arg=CONTENTFUL_SPACE_ID=$$CONTENTFUL_SPACE_ID
      secretEnv: ["CONTENTFUL_CONTENT_DELIVERY_API_KEY", "CONTENTFUL_SPACE_ID"]
    # Deploy container image to Cloud Run
    - name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
      entrypoint: gcloud
      args:
          [
              "run",
              "deploy",
              "glowtify-community",
              "--image",
              "gcr.io/$PROJECT_ID/community-image",
              "--platform",
              "managed",
              "--region",
              "northamerica-northeast1",
              "--allow-unauthenticated",
          ]
availableSecrets:
    secretManager:
        - versionName: projects/$PROJECT_ID/secrets/CONTENTFUL_CONTENT_DELIVERY_API_KEY/versions/latest
          env: "CONTENTFUL_CONTENT_DELIVERY_API_KEY"
        - versionName: projects/$PROJECT_ID/secrets/CONTENTFUL_SPACE_ID/versions/latest
          env: "CONTENTFUL_SPACE_ID"
timeout: 1800s

Expected behavior

Expected $$CONTENTFUL_CONTENT_DELIVERY_API_LEY and $$CONTENTFUL_SPACE_ID to be replaced by the actual secret value like stated in gcloud docs : https://cloud.google.com/build/docs/securing-builds/use-secrets#access-utf8-secrets

If not what is the detailed solution to pass secrets from gcp cloudrun to cloudbuild kaniko

To Reproduce Run the build and wait for value to be replaced by $VALUE_NAME instead of the actual value

Additional Information

Docker file

# Install dependencies only when needed
FROM node:16-alpine AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app

# Install dependencies based on the preferred package manager
COPY package.json yarn.lock* ./
RUN \
  [ -f yarn.lock ] && yarn --frozen-lockfile --prod || \
  (echo "Lockfile not found." && exit 1)

# Rebuild the source code only when needed
FROM node:16-alpine AS builder

ARG CONTENTFUL_CONTENT_DELIVERY_API_KEY
ARG CONTENTFUL_SPACE_ID

WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Redo tsconfig structure.
RUN mv tsconfig.json tsconfig.base.json
RUN mv tsconfig.deployment.json tsconfig.json

# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
# ENV NEXT_TELEMETRY_DISABLED 1

RUN yarn build

# Production image, copy all the files and run next
FROM node:16-alpine AS runner
WORKDIR /app

ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED 1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public

# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000

ENV PORT 3000

CMD ["node", "server.js"]

Triage Notes for the Maintainers

Description	Yes/No
Please check if this a new feature you are proposing	- [ ]
Please check if the build works in docker but not in kaniko	- [x]
Please check if this error is seen when you use --cache flag	- [ ]
Please check if your dockerfile is a multistage dockerfile	- [x]

[x-EricH-x]

I just faced the same issue, after considerable digging, I found this SO answer that successfully passed secretEnv to kaniko via docker run https://stackoverflow.com/a/69242433

the relevant code in the ans:

- id: Build
  name: gcr.io/cloud-builders/docker
  entrypoint: /bin/bash
  args:
  - -c
  - |
   docker run \
      --network=cloudbuild \
      -v /workspace:/workspace \
        gcr.io/kaniko-project/executor:latest \
          --dockerfile /workspace/Dockerfile \
          --build-arg=GITHUBTOKEN=$$GITHUBTOKEN \
          --destination=gcr.io/$PROJECT_ID/myapp:$SHORT_SHA \
          --cache=true \
          --context dir:///workspace/
  secretEnv: ['GITHUBTOKEN']

availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/github_machine_user_pat/versions/latest
      env: GITHUBTOKEN

[x-EricH-x]

@anthonyWalter a side question related to using secretEnv, what are reasons to use secretEnv for passing secrets (like keys, private token, etc)?

I understand that saving secrets in repo is a big no no, but why are passing them as plain text env var insider the ephemeral GCP Cloud Build environment is a concern?

I assume that implies the env var contents are actually leaked/exposed to some external system? (maybe the in the logs?)

Thanks!

[dobesv]

Expected $$CONTENTFUL_CONTENT_DELIVERY_API_LEY and $$CONTENTFUL_SPACE_ID to be replaced by the actual secret value

In the docs you linked, it's running bash -c ... to expand the environment variables instead of running kaniko/executor. That's how those are being expanded in that case.

I assume that implies the env var contents are actually leaked/exposed to some external system?

Build args and env vars are stored into the docker image, generally the secrets used to build the image sometimes aren't meant to be accessible to people using the image (especially if you are building a public image).

[iqbalaydrus]

based on #993 you can do it like so:

    - name: "gcr.io/kaniko-project/executor:latest"
      args:
          - --destination=gcr.io/$PROJECT_ID/community-image
          - --cache=true
          - --build-arg=CONTENTFUL_CONTENT_DELIVERY_API_KEY
          - --build-arg=CONTENTFUL_SPACE_ID
      secretEnv: ["CONTENTFUL_CONTENT_DELIVERY_API_KEY", "CONTENTFUL_SPACE_ID"]

when build-arg is left without value, it will look for environment variables