FAQ | This is a LIVE service | Changelog

Skip to content
Snippets Groups Projects

Draft: feat: genericise token fetching

Closed Dr Rich Wareham requested to merge issue-60-generic-token-fetching into master
2 unresolved threads

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

Closed by Dr Rich WarehamDr Rich Wareham 1 year ago (Jan 17, 2024 10:34am UTC)

Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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:
    • @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 the release-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.

    • Please register or sign in to reply
  • Please register or sign in to reply
    Loading