If I follow the cloud build document, I have to specify encrypted secret on cloudbuild.yaml.
secrets:
- kmsKeyName: projects/[PROJECT-ID]/locations/global/keyRings/[KEYRING-NAME]/cryptoKeys/[KEY-NAME]
secretEnv:
MY_SECRET: <base64-encoded encrypted secret>
Even if it is encrypted, I don't commit secret value at code. Please tell me another way.
ex. via args from gcloud builds submit command or environment variables,...etc
You can use Google Secret Manager instead. We're still updating the documentation, but there is an example of how you can use it with Cloud Build:
First, create a secret:
$ echo -n "my-secret-data" | gcloud beta secrets create "my-api-key" \
--replication-policy "automatic" \
--data-file -
Grant the Cloud Build Service Account permission to access your secret:
$ gcloud beta secrets add-iam-policy-binding "my-api-key" \
--member "serviceAccount:<project-number>@cloudbuild.gserviceaccount.com" \
--role "roles/secretmanager.secretAccessor"
Then retrieve the secret in your build steps:
steps:
- name: 'gcr.io/cloud-builders/gcloud@sha256:c1dfa4702cae9416b28c45c9dcb7d48102043578d80bfdca57488f6179c2211b'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud beta secrets versions access --secret=my-api-key latest > /secrets/my-api-key
volumes:
- name: 'secrets'
path: '/secrets'
- name: 'my-step'
volumes:
- name: 'secrets'
path: '/secrets'
args: # ... /secrets/my-api-key contains the secret
How should I do specify env variables in my-step's container?
What about multiple secrets, do I have to fetch them one at a time? And why not have auto-substitution for values in Secret Manager? Where can I raise a feature request for this?
You can run that gcloud command many times (put each on its own line). A feature request for deeper Cloud Build integration has already been filed.
Hey Seth, love the work on GSM, thanks! Regarding the above, is there any security concern that the secrets are plaintext in the /secrets volume? What if layer caching is used as with Kaniko?
That's definitely a concern and one of the reasons we advocate for having apps talk directly to SM or store in an envvar directly. The fs is the best-available portable solution today, but we're always working on product improvements