User-specific secret variables

How to Use GitLab
1

We are trying to utilize an external container orchestration system in our GitLab CI. The problem that we’ve run into is that we’d like the GitLab CI pipeline to be able to authenticate as the user who triggered the build, by manual trigger (think, deployment to production) or by pushing a commit.

Please correct me if I’m wrong, but the problem seems to be one of getting user-specific secrets into the build. Project secret variables aren’t not user-specific, and the few user-specific variables (GITLAB_USER_ID, GITLAB_USER_EMAIL) are not secret (and, therefore, not sufficient for authentication).

I’m curious what the community thinks about another level of variables, in addition to the ones in the list here:

  1. Trigger variables (take precedence over all)
  2. Secret variables
  3. YAML-defined job-level variables
  4. YAML-defined global variables
  5. Deployment variables
  6. Predefined variables (are the lowest in the chain)

Consider that user profiles could also possess variables that would be injected into the build, alongside existing secret (project) variables (second item in the above list).

There are some problems with this… as noted in the link above, it is up to the build pipeline to maintain the secrecy of these; this may be even more important when they are tied to a specific user.
Related to this, a user may not want all projects to have access to all (or any) variables. You can imagine many complicated schemes for tracking this, but a simple one would be that trusted projects have access to all of your user variables and that (default) untrusted projects have access to none of them.

Thoughts?

2 Likes
2

I could use this also. I think it might be safest to have user variables which are tied to a specific project (or projects) instead of just a general trusted/untrusted distinction.

I would use them as a way to authenticate into a different system needed for deployment, which sounds like the same use case as the OP. Perhaps there is a better, more common, way to do this?

The workaround I’m planning is to have a manual job that, when triggered, sends an e-mail to the user instrucing them to log in manually and run a script (including a customized command line referring to the specific artifacts). The script will then wait while checking for the changes to be completed (the runner does have read access to the deployment environment, just not write access).

3

I believe this could be useful in many situations when the integration is based on the user running the pipeline. This would currently force us to share user specific tokens with other maintainers or go through the hassle of creating a specific technical user account for each case. The latter might depend on other IT teams and could be a massive slowdown and demotivator in building automation.