Project setting to create and send token to runner

Description

For pipeline jobs, we send $CI_REGISTRY_USER and $CI_REGISTRY_PASSWORD so the runner can access the container registry to push and pull images, but the password is a temporary token, only valid while the job runs. Sometimes we use this token in CD, and tell the target platform to use those secrets to pull the image in order to run it. But if that platform needs the secrets after initial deploy, it'll be unauthorized.

We also have a scope of read_registry available for personal access tokens, and currently this is the recommended way of creating credentials for a CD system so it can reliably pull images as needed. But these tokens need to be created manually and stored as project variables in order for the CD system to use them.

What we need is a way to make it easy to pass long-lived, read-only tokens to CD, that can be used by the target platform.

Proposal

  • For each project, automatically create a personal access token with an appropriate scope, and pass it as a variable to the runner, for use in pipeline jobs.
  • We could leverage the existing variables, $CI_REGISTRY_USER and $CI_REGISTRY_PASSWORD, and just turn those into long-lived tokens, but these are read-write, and apply to more than just the registry, and even apply to all projects the triggerer has access to, so have too much scope.
  • We could create new variables for the read-only tokens. This would be acceptable, if slightly clumsy.
  • We could use the existing variables, but have them automatically convert from read-write tokens during pipeline run, to read-only after the run. Also, the scope would need to reduce down to only reading the registry for the current project. I've never seen a system with dynamic scope before, but it is technically easy in our system, and might be the perfect compromise.
  • Because this is an increase in scope, we should consider making this a project setting to enable, and have it disabled by default. But ideally, we'd come up with something reasonable that we'd enable for all projects and avoid having it be configurable.
  • Because of the security concern of long-lived tokens, there needs to be a way to rotate the credentials.
  • Also, if we do go with dynamic scope, we might (eventually) needs to automatically detect failed attempts to use the tokens for writing, to prevent the attack vector of storing a token and trying to use it in a loop until finally the read-write window opens again.

Links / references

Documentation blurb

Overview

What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?

Use cases

Who is this for? Provide one or more use cases.

Feature checklist

Make sure these are completed before closing the issue, with a link to the relevant commit.

Edited by Mark Pundsack