Repository navigation
Send registry tokens only to the token service's own registry - #576
Merged
Merged
Conversation
After a 401 the transport fetches a token from the challenge's realm, using credentials configured for that realm, and sends it to the host that issued the challenge. It trusted that host if it had any configured credentials, even unrelated ones, or shared the realm's registrable domain. The second rule makes every tenant on a shared domain such as jfrog.io, azurecr.io or pkg.dev the same site, and the first hands a token minted from one registry's credentials to another registry the proxy happens to have a key for. A credentialed token now goes only to a registry on the realm's own host and port, to one configured with the same credentials as the realm, or to Docker Hub and GitLab.com, whose registries use a token service on another host. Anonymous tokens are unaffected. The scope in the token request also came from the challenge, so a registry could ask for push access or for other repositories. The proxy only reads, so it now always asks for pull access to the repository in the request path.
The transport remembered a challenge for every /v2/<repository> it was ever challenged on and never forgot one, so a long-running proxy, or a metadata document naming many registries, grew the map without limit. Tokens were only pruned of expired entries, and the expiry came from the token service. Challenges are now kept per registry host, holding only the realm and service, and the pull scope for a request is built from its path, so pulling many repositories from one registry keeps one entry. Both caches have a size limit, evicting an arbitrary challenge or the token that expires soonest, and a token is reused for at most an hour, whatever lifetime the token service claims.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tightens which registries get a bearer token fetched with configured credentials, and bounds the token caches.
jfrog.io,azurecr.ioorpkg.devas one site. Such a token now only goes to a registry on the token service's own host and port, to one configured with the same credentials as the token URL, or to Docker Hub (registry-1.docker.io/index.docker.iowithauth.docker.io) and GitLab.com (registry.gitlab.comwithgitlab.com). Anonymous tokens are unaffected. GHCR, Harbor, Artifactory, ACR, Quay and Artifact Registry serve their token endpoint from the registry host, so they keep working; a self-hosted registry with its token service on another host needs the same credentials configured for both URLs, as the docs now show.repository:<repo>:pullfor the repository in the request path./v2/<repo>and never dropped, and tokens were only pruned of expired entries. Challenges are now kept per registry host, both caches have a size limit, and a token is reused for at most an hour.Tests cover a registry with other credentials, the pull scope, the host matching (including shared-domain tenants), and the cache limits.