CI_JOB_TOKEN получил 404 в другом проекте: проверяем allowlist

Сборочная job забирает пакет из соседнего приватного проекта. Из браузера разработчик видит файл, а запрос с CI_JOB_TOKEN получает отказ или 404. Токен существует, переменная не пустая, поэтому кажется, что дело в URL. Но доступ человека через браузер и межпроектный доступ задания проходят разные проверки.

CI_JOB_TOKEN выдаётся заданию на время его работы и имеет ограниченный набор допустимых операций. Для обращения к другому проекту важны как права пользователя, инициировавшего pipeline, так и настройки принимающего проекта. Allowlist у получателя разрешает использование токенов определённых проектов или групп; она не раздаёт пользователю права, которых у него раньше не было.

Проверять доступ у получателя

Начните с project ID, endpoint и поддерживаемого способа аутентификации. Не всякий API принимает job token. Для разрешённого endpoint токен передают в заголовке JOB-TOKEN, например при загрузке файла пакета по уже известному API-адресу:

curl --fail --location \
  --header "JOB-TOKEN: $CI_JOB_TOKEN" \
  --output package.tar.gz \
  "$PACKAGE_API_URL"

PACKAGE_API_URL здесь должен быть точным адресом нужного файла, без токена в строке. В целевом проекте проверьте список разрешённых проектов для job tokens и добавьте только источник сборки, которому действительно нужен доступ. Названия разделов интерфейса меняются между версиями GitLab, поэтому ориентируйтесь на настройки job token permissions принимающего проекта.

После этого проверьте права пользователя, от имени которого выполняется pipeline. Запуск по расписанию, ручной запуск и pipeline после push могут иметь разного инициатора. Если у одного пользователя есть доступ к пакету, а у другого нет, allowlist сама по себе эту разницу не отменит. Это часто объясняет, почему одинаковый YAML ведёт себя по-разному.

Не расширять доступ ради зелёной job

Проверьте положительный сценарий из разрешённого проекта и отрицательный из постороннего тестового проекта. Второй должен остаться запрещённым. Так вы подтверждаете границу доступа, а не только наличие файла у одного запуска. В журнале достаточно HTTP-статуса, project ID и безопасного пути; сам токен выводить не нужно.

Не заменяйте job token долгоживущим персональным токеном с широкими правами только потому, что он сразу сработал. Сначала определите требуемую операцию и её поддержку. Если job token для неё не подходит, выбирайте другой механизм с минимальным нужным доступом и понятной ротацией, а не переносите доступ всей учётной записи в runner.

Также учтите срок жизни токена: использовать его из отложенного внешнего процесса после завершения job нельзя как постоянный пароль. Для pipeline полезно явно описать владельца пакета, источник запросов и допустимый endpoint. Тогда следующий отказ будет проверяться по короткой цепочке настроек, а не случайной сменой секретов.

Продолжить практику

Исправление одной job полезно закрепить в полном процессе выпуска. В программе курса «GitLab CI/CD: автоматизация сборки и деплоя» — pipeline учебного приложения с проверками, тестами, сборкой Docker-образа, registry и staging. Отдельно разбираются runners, секреты, нестабильные запуски и возврат к предыдущему образу. Такой проект помогает увидеть, как решение внутри одной job влияет на выпуск версии и дальнейший откат.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Окружение задания и повторяемый pipeline.