Job authentication logs not populating

Summary

Job authentication logs are not being populated when job artifacts being requested using CI_JOB_TOKEN

Projects:

Steps to reproduce

  1. Created project https://gitlab.com/issue-reproduce/artifacts-project (Project ID: 70804516)

.gitlab-ci.yml

test:
    script:
        - echo "Artifact" > artifact.txt
    artifacts:
        paths:
            - artifact.txt
  1. Created project https://gitlab.com/issue-reproduce/test-needs-artifacts (Project ID: 70806635)

.gitlab-ci.yml

test_needs_artifacts:
    needs:
        - project: issue-reproduce/artifacts-project
          job: test
          ref: main
          artifacts: true
    script:
        - cat artifact.txt
  1. Created project https://gitlab.com/issue-reproduce/test-artifacts-api (Project ID: 70806724)

.gitlab-ci.yml

test_artifacts_api:
    script:
        # https://docs.gitlab.com/ci/jobs/job_artifacts/#with-a-cicd-job-token
        - apt update && apt install -y unzip
        - 'curl --location --output artifacts.zip "https://gitlab.com/api/v4/projects/70804516/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"'
        - ls -la artifacts.zip
        - unzip artifacts.zip
        - cat artifact.txt
  1. In the CI/CD job token permissions settings for artifacts_project, the group issue-reproduce was added to the allowlist.

After waiting 5–15 minutes, we don’t see any authorization logs populated:

Ci::JobToken::Authorization.where(accessed_project_id: 70804516)
=> 
[#<Ci::JobToken::Authorization:0x00007fcae44ff0e0
  id: 177213339,
  accessed_project_id: 70804516,
  origin_project_id: 70804516,
  last_authorized_at: Fri, 13 Jun 2025 15:37:51.089362000 UTC +00:00,
  job_token_policies: {}>]

We have only one record for the accessed project itself.

image

Example Project

What is the current bug behavior?

Job authentication logs are not appearing on GitLab.com.

However, the logs are being populated in the local gdk setup environment.

What is the expected correct behavior?

Logs are populated on accessed project in Settings -> CI/CD -> Job token permissions -> Authentication logs area.

Or in rails console Ci::JobToken::Authorization.where(accessed_project_id: accessed_project_id)

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Since CI job token access is captured asynchronously by a background worker, further investigation is required on the Gitlab.com infrastructure side, as we most likely lost logs in a background worker or middleware.

  1. Record a SafeRequestStore a cross-project access attempy - https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/ci/job_token/authorization.rb?ref_type=heads#L32
  2. https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/ci/job_token/authorization.rb?ref_type=heads#L47
# We are tracking ci job token access to project resources, but we
# are not yet persisting this log until a request successfully
# completes. We will do that in a middleware. This is because the policy
# rule about job token scope may be satisfied but a subsequent rule in
# the Declarative Policies may block the authorization

Possible fixes

The middleware returns a 302 Redirect, but with the current logic, this is not treated as a success:

def call(env)
  response = @app.call(env)

  # We only log authorizations leading to successful requests.
  Ci::JobToken::Authorization.log_captures_async if success?(response[0])

  response
end

private

def success?(status)
  (200..299).cover?(status)
end

A quick fix:

def success?(status)
  (200..299).cover?(status) || status == 302
end

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖