Stefano
Stefano

Reputation: 422

PROJECT_ID env and Secret Manager Access

I would like to use the Secret Manager to store a credential to our artifactory, within a cloud build step. I have it working using a build similar to:

steps:
- name: 'busybox:glibc'
  entrypoint: 'sh'
  args: ['-c', 'env']
  secretEnv: ['SECRET_VALUE']
availableSecrets:
  secretManager:
  - versionName: "projects/PROJECT_ID/secrets/TEST-SECRET/versions/1"
    env: 'SECRET_VALUE'

All great, no problems - I then try and slightly improve it to:

steps:
- name: 'busybox:glibc'
  entrypoint: 'sh'
  args: ['-c', 'env']
  secretEnv: ['SECRET_VALUE']
availableSecrets:
  secretManager:
  - versionName: "projects/$PROJECT_ID/secrets/TEST-SECRET/versions/1"
    env: 'SECRET_VALUE'

But then it throws the error: ERROR: (gcloud.builds.submit) INVALID_ARGUMENT: failed to get secret name from secret version "projects/$PROJECT_ID/secrets/TEST-SECRET/versions/1"

I have been able to add a TRIGGER level env var (SECRET_MANAGER_PROJECT_ID), and that works fine. The only issue that as that is a trigger env, it is not available on rebuild, which breaks a lot of things.

Does anyone know how to get the PROJECT_ID of a Secret Manager from within CloudBuild without using a Trigger Param?

Upvotes: 3

Views: 2341

Answers (3)

guillaume blaquiere
guillaume blaquiere

Reputation: 75810

For now, it's not possible to set dynamic value in the secret field. I already provided this feedback directly to the Google Cloud PM, it has been take into account, but I don't have more info to share, especially for the availability.


EDIT 1

(January 22). Thanks to Seza443 comment, I tested again and now it works with automatically populated variable (PROJECT_ID and PROJECT_NUMBER), but also with customer defined substitution variables!

Upvotes: 3

Tanner Stern
Tanner Stern

Reputation: 235

It appears that Cloud Build now allows for the use of substitution variables within the availableSecrets field of a build configuration.

From Google Cloud's documentation on using secrets:

After all the build steps, add an availableSecrets field to specify the secret version and environment variables to use for your secret. You can include substitution variables in the value of the secretVersion field. You can specify more than one secret in a build.

I was able to use the $PROJECT_ID variable in my own build configuration like so:

...
availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/api-key/versions/latest
      env: API_KEY

Granted, there appears to be (at least at present) some discrepancy between the documentation quoted above and the recommended configuration file schema. In the documentation they refer to secretVersion, but that appears to have changed to versionName. In either case, it seems to work properly.

Upvotes: 2

Related Questions