如何在Google Cloud Build中使用Kaniko非exec入口点定义构建参数

Absolutely, you can pull this off without forcing local developers to configure secret files. The trick is overriding Kaniko’s default entrypoint to use a shell, then manually invoking the Kaniko executor while passing your secret directly as a build argument—either from a mounted environment variable or a temporary secret file.

Option 1: Use a Secret Mounted as an Environment Variable (Cleaner Approach) #

This avoids file handling entirely and keeps your configuration streamlined:

steps:
- id: 'Build with Kaniko & GitHub PAT'
  name: 'gcr.io/kaniko-project/executor:latest'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
    /kaniko/executor \
      --destination=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$SHORT_SHA \
      --cache=true \
      --cache-ttl=6h \
      --build-arg PERSONAL_ACCESS_TOKEN_GITHUB=$PERSONAL_ACCESS_TOKEN_GITHUB
  # Mount your Secret Manager secret as an environment variable
  secrets:
  - secretManager: projects/$PROJECT_ID/secrets/your-github-pat-secret/versions/latest
    secretEnv:
      PERSONAL_ACCESS_TOKEN_GITHUB: 'projects/$PROJECT_ID/secrets/your-github-pat-secret/versions/latest'

Option 2: Mount the Secret as a File (Familiar Pattern from Docker) #

If you prefer the file-reading workflow you used with Docker, you can mount the secret to a temporary file and read it in the shell command:

steps:
- id: 'Build with Kaniko & GitHub PAT'
  name: 'gcr.io/kaniko-project/executor:latest'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
    /kaniko/executor \
      --destination=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$SHORT_SHA \
      --cache=true \
      --cache-ttl=6h \
      --build-arg PERSONAL_ACCESS_TOKEN_GITHUB=$(cat /workspace/secrets/github-pat.txt)
  # Define a volume to hold the secret file
  volumes:
  - name: 'secrets'
    path: '/workspace/secrets'
  # Mount the Secret Manager secret to the volume path
  secrets:
  - secretManager: projects/$PROJECT_ID/secrets/your-github-pat-secret/versions/latest
    mountPath: '/workspace/secrets/github-pat.txt'

Key Details to Keep in Mind: #

1. Shell Availability: The official Kaniko executor image includes sh (though bash isn’t guaranteed), so using entrypoint: 'sh' is the most reliable choice.
2. Local Build Compatibility: This setup doesn’t disrupt local development. Developers can still build images locally with the same command they’re used to:

   docker build --build-arg PERSONAL_ACCESS_TOKEN_GITHUB=their-personal-token .
   

3. Overriding the Default Entrypoint: Kaniko’s default entrypoint is /kaniko/executor, so switching to sh means we need to explicitly call the executor binary with all our desired arguments.

内容的提问来源于stack exchange，提问作者thclark