Draft: feat: genericise token fetching
Add generic job templates which can fetch a Google secret into an environment variable and fetch the Gitlab API token from the right Google secret.
Update the release-it.yml template to make use of this.
Closes #60 (closed)
Merge request reports
Activity
assigned to @rjw57
requested review from @rk725
- google-secrets.yml 0 → 100644
1 # Generic template job which uses the gcloud CLI to fetch a secret into an environment variable for later jobs to use. 2 # The job assumes that gcloud can authenticate itself via application default credentials. 3 # 4 # One can choose to set the following variables to access the secret: 5 # 6 # - GOOGLE_PROJECT (required), GOOGLE_SECRET_NAME (required) and GOOGLE_SECRET_VERSION (default: "latest"), or 7 # - GOOGLE_SECRET_ID which should be of the form "projects/{project id}/secrets/{secret name}/versions/{version id}" 8 # 9 # If you need to impersonate a service account to fetch the secret, that can be specified by setting the 10 # GOOGLE_IMPERSONATE_SERVICE_ACCOUNT variable. 11 # 12 # The secret itself is available to downstream jobs as an environment variable. The ENVIRONMENT_VARIABLE_NAME variable 13 # must be set to specify the destination environment variable name. 14 .fetch-google-secret: I'm wondering about having a
.fetch-google-secret-default-credentials
which uses the k8s GitLab runners we have (essentially just addstags
to the template) and.fetch-google-secret-identity-federation
which uses workload identity federation and job id tokens to authenticate as a service account.Edited by Dr Rich Wareham
@rjw57 I've had a look at this but I'm afraid I can't get behind it as it uses artefacts to store secrets which is not something we want to do. For example, if we enabled this job on a public repository any unauthenticated user could simply view the latest
secrets.env
artefact and download it, for example see my quick demo of this issue by going here in an incognito browser session. Even if we had an internal policy to disallow enabling this on public repositories (which would be hard to police) we would still be making these artefacts available to people who may not be authorised to view the secret values, for example external users who have been granted permissions to a particular repo.Regarding using the workload identity/job id tokens method, I am open to the idea, however, I do note that it's a very new feature (support for GCP at least) which is released in 16.8 by the looks of it - we're currently running 16.6. I also feel that we're already solving the problem in our own way with our
gke-runner-infrastructure
configuration etc. So, IMO unless switching methods gives us any massive benefits I'd be inclined to continue as we are, at least in the short term.I do agree that it would be good to genericise the token fetching in some way. When I implemented the, admittedly very verbose, code in the
release-it.yml
template I did make a mental note to revisit it in the future once usage increases. However, I think the way we achieve this should probably be moving/refactoring the code from therelease-it.yml
template into a shared script which is then called from individual jobs as and when secrets are required. The individual job would then be responsible for setting any environment variables. I would be more than happy to catch up on this and discuss/brainstorm other potential options.I agree. I'll close this MR.
@rk725 and I had an offline chat. I'll add a summary to #60 (closed) and open appropriate issues.