ate-setup: widen digest-lookup auth and pass through pinned tags - #1391
Merged
Haven Xia (HavenXia) merged 1 commit intoSep 2, 2026
Merged
Conversation
Pinning a pre-built image to its digest authenticated the lookup with the docker config file alone. ko resolves its own credentials through a multi-keychain, and the GCP half of it is what the flag's own audience needs: someone installing a published release onto GKE, whose Artifact Registry credentials are gcloud's rather than a helper wired into ~/.docker/config.json, got a working build from source and a 401 from --image-repo. Add GCP to the keychain. ECR and ACR need credential-helper modules this repository does not depend on, so those registries still need a docker login, and the doc comment no longer claims the lookup authenticates the way ko does. Pass a tag that already carries a digest through as written. The reference was built as <repo>/<image>:<tag> and then had the looked-up digest appended unconditionally, so --image-tag v1@sha256:... produced <repo>/<image>:v1@sha256:...@sha256:..., which no registry can parse. That input resolved before the tags were pinned. Document both in commands.md, which described the digest lookup as needing read access to the repository but never said how it authenticates.
Anna Pendleton (annapendleton)
requested a review
from Aditya Shantanu (aditya-shantanu)
September 2, 2026 05:52
2 tasks
Haven Xia (HavenXia)
approved these changes
Sep 2, 2026
Anna Pendleton (annapendleton)
pushed a commit
that referenced
this pull request
Sep 2, 2026
…1400) With --image-repo the image tag becomes the substrate version, which names the atelet DaemonSet and the node label. A tag written with its digest, v1@sha256:..., is a valid image reference but not a valid label value, so the install failed at the atelet step unless VERSION was also set. The version is now the tag alone; the digest still pins the image. Followup for #1391 - [ ] Tests pass - [ ] Appropriate changes to documentation are included in the PR
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
2 participants
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.
Two follow-ups to the pre-built image install.
Digest lookups authenticated with the docker config file alone. Someone
installing a published release onto GKE, whose Artifact Registry credentials are
gcloud's rather than a credential helper wired into
~/.docker/config.json, gota working build from source and a 401 from
--image-repo. The lookup keychain isnow
authn.NewMultiKeychain(authn.DefaultKeychain, google.Keychain), the samerelative order ko uses.
DefaultKeychainstays first, so~/.docker/config.jsonstill wins wherever it has an entry, and
google.KeychainreturnsAnonymousimmediately for any non-Google registry, so this is a no-op for Docker Hub, ghcr,
ECR, ACR and the Kind local registry. ECR and ACR would need credential-helper
modules this repository does not depend on, so those still need a
docker login;the doc comment no longer claims the lookup authenticates the way ko does.
Separately,
pinappended the looked-up digest unconditionally, so--image-tag v1@sha256:...produced<repo>/<image>:v1@sha256:...@sha256:...,which no registry can parse. A tag that already carries a digest now passes
through as written.
No dependency change:
pkg/v1/googlewas already vendored, andateletalreadyuses the same package for its image pulls.
Verified against Artifact Registry with
DOCKER_CONFIGpointed at an emptydirectory, which reproduces the affected setup — without this change the lookup
fails with
DENIED: Unauthenticated request, with it the tag resolves. Alsoinstalled on a Kind cluster from a local registry, where all five control-plane
images came up pinned to the digests the registry published.