## :dart: What Implement `ArtifactRegistry::TokenExchange#token_for(current_user, slug)`, the per-user credential seam of the Artifact Registry Ruby client. It returns `nil` today, so every per-user call to the Artifact Registry management API fails closed before a request is issued. This is the per-user half of the client's two credential seams. The service half is https://gitlab.com/gitlab-org/gitlab/-/work_items/617724. ## :mag: Current state - `ee/lib/artifact_registry/token_exchange.rb` — `#token_for` returns `nil`, with the doc comment "This is a stub: it returns nil until the real exchange is built." - `ArtifactRegistry::Client#user_request` (`ee/lib/artifact_registry/client.rb`) acquires the credential through this seam, and `#authed_request` raises `AuthorizationError` when the token is blank. The client is fail-closed by design, so there is no fallback path. - Nothing injects a functional provider. `ArtifactRegistry::CachesClient#artifact_registry_client` builds `Client.new(current_user:)` with no `token_exchange:` argument, so the null default is what production code runs. Every per-user client method is affected — `repository`, `repositories`, `create_repository`, `update_repository`, `delete_repository`, `packages`, `images` — which is the whole `/api/v1/:slug/...` management-API surface the UI renders from. Their callers are the GraphQL resolvers and mutations under `ee/app/graphql/resolvers/artifact_registry/` and `ee/app/graphql/mutations/artifact_registry/`, reached through `Resolvers::ArtifactRegistry::AcquiresClient`. The service seam is unaffected in shape but blocked on its own credential: `#service_request` binds `ArtifactRegistry::ServiceCredential#token`, which also returns `nil` pending https://gitlab.com/gitlab-org/gitlab/-/work_items/617724. ## :compass: Scope - A functional `token_for(current_user, slug)` returning a short-lived Artifact-Registry-audience JWT for the acting user. - Wiring it in place of the null default, so `CachesClient` builds a client with a working provider. - Whether the token is minted in-process through `Authn::TokenExchange::TokenIssuer` or over HTTP through `POST /api/v4/token_exchange`. The in-process route was proposed as https://gitlab.com/gitlab-org/gitlab/-/work_items/601467 and deferred; its proof of concept was closed and kept as a reference. - Caching and reuse policy for a minted token, and the behaviour when the caller is a principal type the endpoint cannot mint for (a deploy token has no `sub`/organization claim shape, and `POST /api/v4/token_exchange` rejects it). - Closing ADR-014 open question 2 through a handbook merge request. See the note below. ## :books: Why this has no tracking issue today Three specs each declare it out of scope and defer to the next, and the chain ends at an ADR open question that is now stale: - `monolith/S02` (the client) ships both seams with null defaults and assigns the interim providers to its consumers as "consumer-side wiring": the per-user bootstrap exchange to `monolith/S03`, the service bootstrap token to `monolith/S10`. - `monolith/S03` lists "Real token exchange and the credential format — the S02 credential seam and ADR-014 open question 2" under **Out of scope**, and its Follow-ups section reads "None". The interim per-user wiring S02 assigned to it was never built. - `monolith/S04` repeats the same Out of scope line. - ADR-014 open question 2 states that "the credential format, claim shape, and minting service are not yet specified", and that the Ruby client's credential acquisition step is "deliberately left abstract in this ADR". That last premise no longer holds. ADR-020 Rev 2 is merged, `POST /api/v4/token_exchange` is shipped and entitlement-gated, and the staging path has been exercised end to end (see the smoke test on https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/473). The format, claim shape, and minting service are specified; the question was simply never closed, so no spec re-homed the work. ## :warning: Consequence once this lands `monolith/S02` records a per-user plaintext residual that this change makes reachable: `Client#guard_service_transport!` refuses plaintext `http` on the service path only, so a per-user bearer token can travel in the clear over `http` in any environment. The spec names "the first functional per-user token exchange" as the trigger that closes it. It has no issue of its own yet and should get one alongside this work. ## :link: Related - https://gitlab.com/gitlab-org/gitlab/-/work_items/617724 — the service credential half, and the settings and secret mount it needs - https://gitlab.com/gitlab-org/gitlab/-/work_items/619471 — chart appConfig keys - https://gitlab.com/gitlab-org/gitlab/-/work_items/619481 — pointing staging Rails at the Artifact Registry staging service - https://gitlab.com/gitlab-org/gitlab/-/work_items/619494 — the organization still reports a stub slug, so the `slug` argument passed to `token_for` is wrong independently of this issue - https://gitlab.com/gitlab-org/gitlab/-/work_items/601467 — in-Rails token issuance without a self-directed HTTP call, deferred - https://gitlab.com/gitlab-org/gitlab/-/work_items/602638 — the frontend slice whose scope the stub comment deferred to, which never covered credential acquisition