When using Pipeline Triggers and Trigger Tokens, the Pipeline impersonates Token Owner, not Trigger User

GitLab CI/CD
,
1

Summary

When running a Pipeline via a Trigger configured with a Trigger Token per the documentation: Trigger pipelines by using the API | GitLab, the triggered pipelines are being run with the identity of the Trigger Token creator rather than the user who started the Trigger.

Use Case and Details

In my gitlab.com setup, I have a ChatOps integration with Slack in a root level project which is used to trigger multiple downstream projects (multi-repo).

At a high level, the .gitlab-ci.yaml at the root is structured like this:

stages:
  - chat
  - trigger

.chat-deploy:
  script:
  - # curl command here with the token and some environment variables

deploy: 
  stage: chat
  variables:
    CHAT_DEPLOY_ENV: development
  script:
    - !reference [.chat-deploy, script]
  rules:
    - if: '$CI_PIPELINE_SOURCE == "chat"'

deploy-demo: 
  stage: chat
  variables:
    CHAT_DEPLOY_ENV: demo
  script:
    - !reference [.chat-deploy, script]
  rules:
    - if: '$CI_PIPELINE_SOURCE == "chat"'

deploy-project1:
  stage: trigger
  trigger:
    project: # Project info here.
    strategy: depend
  rules:
    if: $CHAT_DEPLOY_ENV && ... # Simplified here

deploy-project2:
  stage: trigger
  trigger:
    project: # Project info here.
    strategy: depend
  rules:
    if: $CHAT_DEPLOY_ENV && ... # Simplified here

# Multiple other downstream projects...

You can observe that it is “self-referential”; the chat arguments are parsed and converted to environment variables on the curl POST command.

This works great and the script runs fine.

This produces two pipelines:

  1. one that represents the chat interaction and
  2. a second that represents the downstream job(s). The parameters into the chat allow selection of the downstream job(s) to run.

The deploy-project# jobs have some conditions to search for project names in one of the chat parameters so we can issue a command like:

/gitlab root run deploy deploy-project1,deploy-project2

This way the team can deploy parts of the multi-repo based on what they are working on.

The Problem

When the initial job kicks off, it is correctly attributed to the user that issued to the chatops command in Slack.

However, the subsequent jobs triggered by the curl command are attributed to the owner of the Pipeline Trigger Token. So if I’m a Maintainer and create the Pipeline Trigger token, it attributes the Triggered workflows to me instead of the to caller.

Using CI_JOB_TOKEN causes a different issue and raises this error: Cyclical multi-project pipelines too strict: "job would create infinitely looping pipelines" (#333073) · Issues · GitLab.org / GitLab · GitLab.

I have done some research on the Trigger Token and it seems that there’s no mechanism to assign the ownership of the Token and that still seems broken. Ideally, the Pipeline Trigger would have a mechanism to impersonate the identity of the caller or pass through the identity of the caller rather than the identity of the Token creator.

Question

  • Is there a workaround?
  • Is there a different way to configure this?
  • Should this be a feature request?

There are a few issues I’ve found related to this behavior:

2

Thank you for the post, I was looking into this just today.

As well, it seems like these are always attached to a particular user, rather unlike “project tokens” which are scoped to the project not the user. I wonder what happens if work removes my access, do all these trigger tokens stop working or something?

3

It seems that the CI_JOB_TOKEN is the one the use. However, when using this to trigger downstream workflows in this pattern where it is:

(Slack)->(Root Project YAML Chat)->(Root Project YAML Triggers)->(Downstream)

This fails with an error “job would create infinitely looping pipelines” (in this case, it would not).

You may or may not be able to use the CI_JOB_TOKEN for your use case.

What is interesting to me is that there seems to be two paths that the application is using to determine if the downstream project would cause an infinite loop. The delta between CI_JOB_TOKEN and the Trigger Token doesn’t change the possibility of looping when the workflow is re-entrant since it is only changing the identity of the user assigned to the workflow.

1 Like