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.
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:
- one that represents the chat interaction and
- a second that represents the downstream job(s). The parameters into the chat allow selection of the downstream job(s) to run.
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.
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.
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.
- 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:
- Maintainers/Owners can still impersonate each other as trigger token doesnt change (#58312) · Issues · GitLab.org / GitLab FOSS · GitLab
- Allow pipelines triggers to be owned by other users (#18618) · Issues · GitLab.org / GitLab · GitLab
- How to see the user who called the Pipeline Trigger Job in the Gitlab CI? - Stack Overflow