<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Collaborate/take over this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=629690) </details> <!--IssueSummary end--> ## Problem Artifact Registry records who published a Maven or npm version, and nothing about what built it. Container manifests record neither. Hosted Maven and npm versions carry `created_by`, written from the token-exchange payload's `gitlab.local_id`, first publish wins. The same `Version` resource declares `project_id` and `git_commit_sha` as required (nullable) fields, and both read `null` on every version. Pipeline id exists nowhere: no Artifact Registry column, no contract field, no Ruby client attribute, no GraphQL field, no UI. Container manifests carry no attribution at all: `container_manifests` has no `gitlab_*` column, and no container schema in the contract has an attribution field. The cause is the ADR-020 token-exchange payload. Its nested `gitlab` claim carries the principal (`origin`, `origin_id`, `local_id`, `identity_kind`, `organization_role`) and nothing about the CI job, so Artifact Registry cannot tell a CI publish from a manual one. The Package Registry already does this: it records the pipeline per package in `packages_build_infos` and renders `Built by pipeline %{link} triggered %{datetime} by %{author}` in the package history. ## Proposal The CI/CD ID token is the source. The job presents its ID token at `POST /api/v4/token_exchange`; the endpoint verifies it as a relying party against a fixed exchange audience and copies `job_project_id`, `sha` and `pipeline_id` into the existing `gitlab.job` object (`project_id`, `git_commit_sha`, `pipeline_id`) of the token it mints. Nothing is read from the job record: the endpoint is slated to move into the IAM STS, which has no access to the Rails database, and the CI job token carries only the project id. Decided in [AR ADR-020](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/artifact_registry/decisions/020_authentication_flow/) (Token issuance R1, Alternatives considered); the Auth side is in [AUTH-021](https://gitlab.com/gitlab-org/architecture/auth-architecture/design-doc/-/blob/main/decisions/021-modular-service-token-payload-schema.md), "Artifact Registry (first consumer)". The fields are build metadata, not provenance: they say which job, pipeline and project minted the publish credential and do not bind to the published bytes. SLSA-style attestation is the upgrade path, recorded as an alternative in ADR-020. History: the first implementation (!256927) read the claims from the job record in Rails and was reverted (!258494) once the STS constraint surfaced in !257162. #630473, carrying the claims in the CI job token JWT, is closed as not needed. ## Container attribution anchor: the manifest Attribution lands on the manifest, not the tag. A manifest is the immutable, content-addressed artifact a push creates, the analog of a version, and the monolith already renders a manifest detail page and sidebar. A tag is a movable pointer, the analog of an npm dist-tag: moving a tag onto an existing digest is not a build, so attributing the build to whoever moved the tag would be wrong. First push wins, as on versions, so a re-push of an existing digest leaves the row unchanged. ## Already in place, not part of this issue 1. **Artifact Registry schema.** `maven_versions` and `npm_versions` each carry `gitlab_user_id`, `gitlab_project_id`, and `gitlab_git_commit_sha`. 1. **The contract.** `created_by`, `project_id`, and `git_commit_sha` are required (nullable) on the `Version` schema in `api/openapi/v1.yaml`. 1. **Ruby client.** `ee/lib/artifact_registry/version.rb` exposes all three. 1. **GraphQL.** `ArtifactRegistryVersion` exposes `createdBy`, `project`, `commitSha`, and `commitPath`, with the commit fields null unless the viewer can read the project's code (`ee/app/graphql/types/artifact_registry/version_type.rb`). 1. **Frontend.** `version_source.js` builds the "Published to project by author" line, and `version_sidebar.vue` and `versions_table.vue` link the commit. So project and commit on versions need no monolith or design work after the payload carries them. Pipeline id and container manifests do, under Downstream. ## Scope 1. **Token exchange accepts the CI/CD ID token** and copies `gitlab.job` from it: #633754 (Auth team). Carries the audience rule, the TTL cap and the audit event. 1. **Default ID-token issuance** for jobs in organizations with the Artifact Registry enabled: #633755 (Artifact Registry team, with CI Platform or Pipeline Security and AppSec). 1. **Client side presents the ID token** at exchange: #633756 (Artifact Registry team), after #633754 is deployed. 1. **AppSec confirms the exchange audience value.** Placeholder `gitlab-token-exchange`; any fixed, single-audience string satisfies the design, and the exact-match rule must not change. Comment on the closed Artifact Registry review (gitlab-com/gl-security/product-security/appsec/appsec-reviews#295) or a new review issue. Gates the merge of #633754. 1. **Rename the UI fields** from provenance to build metadata, so one concept has one name (requested in review of the ADR). Done: ADR-020 amended (gitlab-com/content-sites/handbook!21420), AUTH-021 paragraph (gitlab-org/architecture/auth-architecture/design-doc!144 and !154), `pkg/userauth` docs and godoc (gitlab-org/auth/iam!860), the revert, #630473 closed. The shared verifier already surfaces `gitlab.job` (gitlab-org/auth/iam!705). Two behaviours to preserve: - `tokenFromClaims` ignores unknown claims rather than rejecting them, and a missing or malformed `gitlab.job` reads as "no build metadata"; a publish never fails over it. - On a non-CI publish (personal access token, OAuth token) and on a job-token exchange the object is absent and the columns stay `NULL`. One consequence: an ID-token exchange authenticates as the job's user (`user_id`), the same principal a job-token exchange yields today, so a CI publish is attributed to a real person alongside the build metadata. ## Downstream The payload change is inert until these land. 1. **Version writes.** Two `VALUES` entries at `FindOrCreateVersion` (`internal/datastore/maven_versions.go`) and `InsertNpmVersion` (`internal/datastore/npm_versions.go`), fed the way `Identity.GitLabUserID` in `internal/auth/auth.go` feeds `gitlab_user_id`, plus a new `gitlab_pipeline_id` column on both tables and a `pipeline_id` field on the `Version` schema. Tracked, project and commit only so far, in gitlab-org/ops/artifact-registry#1275+s. Its scope needs widening to the pipeline. 1. **Manifest writes.** Four `gitlab_*` columns on `container_manifests` (user, project, commit, pipeline), written by `ContainerManifestPersister.PersistManifest` (`internal/datastore/container_manifest_persister.go`) from the identity the OCI push handler already authenticated, first push wins, and the four fields on the `ContainerManifest` schema. Each of the three tables is hash-partitioned 64 ways, so each column is a migration across 64 partitions. No issue yet. 1. **Monolith surfaces.** `ee/lib/artifact_registry/version.rb` and `manifest.rb` gain the new attributes, `ArtifactRegistryVersion` gains `pipeline` and `pipelinePath` gated the way the commit fields are (null unless the viewer can read the project's pipelines), `ArtifactRegistryManifest` gains the same source fields the version type has, and `version_source.js` and the manifest sidebar render the pipeline link. No issue yet. ## Out of scope 1. **The docker credential flow.** Whether the Rails endpoint becomes a Docker-compatible token realm is gitlab-org/gitlab#604870+s. Until then a job exchanges `$CI_JOB_TOKEN` itself and passes the JWT to `docker login`. 1. **Automatic CI authentication.** Nothing injects an Artifact Registry address or credential into the job environment, so a job hand-rolls the exchange and writes the JWT into `.npmrc`, `settings.xml`, or `docker login` itself. The staging measurement of that path, including the triggering-user principal above, is gitlab-org/ops/artifact-registry#1269+s. ## Sequencing 1. #633754 and the AppSec audience confirmation run in parallel; #633754 merges after the confirmation. 1. #633755 runs in parallel, with the CI Platform or Pipeline Security review. 1. #633756 after #633754 is deployed. 1. Artifact Registry `go.mod` bump if `pkg/userauth` changes, then the writes (versions and manifests) and the monolith surfaces under Downstream. Until #633755 lands, or where a project does not opt in with an `id_tokens:` block, a CI publish records no build metadata, which is today's behaviour. ## Links - gitlab-org/ops/artifact-registry#1151+s, the shipped `created_by` half - gitlab-org/ops/artifact-registry#1149+s, the UI umbrella - gitlab-org/gitlab#599087+s, cross-boundary job-token exchange for remote runners - gitlab-org/gitlab#595148+s, auth and authorization direction for the modular service model - gitlab-org/gitlab#601475+s, token-exchange endpoint - gitlab-org/architecture/auth-architecture/design-doc!144+s, the review that moved the source to the ID token