As noted here in GCP documentation for Cloud Build, you can reference secrets without writing explicit gcloud commands by using the "availableSecrets" block. This works great for global secrets, but it does not seem to work for regional secrets.
The proper naming for a regional secret is "projects/(project)/locations/(location)/secrets/(secret_name)", note the location part. When including a secret like this in the "availableSecrets" block, Cloud Build errors immediately, saying
invalid build: invalid secrets: secretManager version "projects/(project)/locations/(location)/secrets/(secret_name)/versions/1" is not a valid SecretManager version resource
I'm assuming GCP just doesn't yet support this functionality for regional secrets? It mentions nowhere in the documentation the location of the secrets that can be used.
Yes, Cuurently it is not possible to pull regional secrets from GCP into Cloud Build config file.There is a feature request raised for this at issue tracker, Which is still open further progress can be tracked there.
A workaround is to add a step that manually retrieves these regional secrets and persists them in a file in /workspace or other persistent volume, and then reads those back out in the step that wants to use them.
An example of this would be:
steps:
- name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- -c
- |
gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.us-central1.rep.googleapis.com/ &&
touch /workspace/.env &&
echo SECRET=$$(gcloud secrets versions access latest --secret=uc1-foo --location=us-central1) >> /workspace/.env
- name: 'gcr.io/cloud-builders/docker'
entrypoint: 'bash'
args:
- -c
- |
set -o allexport &&
source /workspace/.env &&
set +o allexport &&
# `env` here proves that the secrets are accessible as environment variables.
# Should be substituted with whatever user commands need to use them
env