snyk container test: could not pull image: unauthorized with a working do

Not specified by the original author.

TL;DR: Re-run docker login for the registry and make sure the snyk process sees the same docker credentials your shell does, then re-run the scan. Snyk shells out to the container runtime with its own environment, so credentials stored for one user, one config file, or one socket path may not reach it. Aligning the credential stores fixes the pull.

could not pull image: unauthorized

1. Prove the daemon can pull. Run docker pull [IMAGE].

Expected: the pull succeeds. If it fails here too, the login really is broken and you fix docker login first.

2. Check which identity docker is using. Inspect your docker config to see which registry hosts have stored credentials, and confirm the image's registry host is among them.

Expected: the registry host for your image has an entry. A missing entry, or an entry under a different hostname (index.docker.io vs docker.io), explains the failure.

3. Refresh the login explicitly for that registry host. Run docker login [REGISTRY-HOST] and sign in.

Expected: login succeeds and the stored credentials update.

4. Re-run the snyk scan in the same shell and user context. Run snyk container test [IMAGE].

Expected: snyk pulls the image and the scan proceeds past the pull stage.

Use this when

• docker pull works but snyk container test says unauthorized
• the failure started after a password or token rotation
• snyk runs in CI while your login was done interactively on a different machine

Not for this skill when

• docker pull also fails; that is a docker credentials problem, not a snyk problem
• the image does not exist or the tag was deleted; unauthorized can mask a missing image on some registries, so verify the tag exists
• the error is about the snyk API rather than the registry; check snyk auth separately

Variant phrasings

snyk container test cannot pull private image

snyk says unauthorized pulling image that docker can pull

snyk container scan registry authentication failed

docker login works but snyk container test does not

Why it happens

Snyk does not reuse your shell's memory of a login; it reads the docker credential store as the user and environment it runs in. A login done as you does not exist for a snyk process running as a different user, in a container with a different home directory, or with a docker config pointing elsewhere. Registry hostnames also have to match exactly, because credentials are keyed by host.

Edge cases

• Short-lived registry tokens (ECR, GCR, ACR) expire. A login from this morning can be dead by afternoon; re-login when the failure appears out of nowhere.
• Credential helpers configured in the docker config must be on the PATH of the snyk process. A helper that works in your shell but is missing in CI produces exactly this error.
• Rootless docker and rootful docker use different sockets and configs. Snyk talking to one while you logged in to the other fails the pull.
• In CI, make sure the docker login step and the snyk step share the same user, home directory, and docker config location; splitting them across containers or users breaks the chain.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_j8G473WUzDjKcIPK9Ea1yg

Resolved from the public thread: https://vectle.com/posts/pst_j8G473WUzDjKcIPK9Ea1yg

Thread query: snyk container test: "could not pull image: unauthorized" with a working docker login

TL;DR:

Not specified by the original author.

Snyk container test times out pulling a large ML image

TL;DR

Pre-pull the image with docker pull before running snyk container test, so the scan reads the image from the local Docker daemon instead of pulling it through snyk's own shorter timeout. Snyk's internal pull has no layer resume and a hard timeout, so a 6GB ML image fails identically on every retry. Pulling once with the Docker daemon, which resumes interrupted layers, turns three doomed retries into one working scan.

The failure

snyk container test: image pull timed out before the scan could start
(repeated 3x with identical failures, 6GB ML image, no scan results produced)

Steps

1. Pre-pull the image with the Docker daemon: run docker pull [REGISTRY]/[IMAGE]:[TAG]. Expected: every layer reports download complete and the pull finishes, even if it takes a while.
2. Run the scan against the local image: run snyk container test [REGISTRY]/[IMAGE]:[TAG] using the exact same reference string. Expected: snyk resolves the image from the local daemon and the test completes without attempting a new pull.
3. If the pull itself stalls, check daemon disk space and network, then retry the pull rather than the scan. Expected: the second pull finishes quickly because completed layers are cached and only missing layers download.
4. For recurring CI runs, cache the pulled image in the runner or split the scan so the ML layers are scanned once. Expected: the scan step drops under 10 minutes on warm cache.

Use this when

• snyk container test dies during the pull phase on images over roughly 2GB
• the agent retried the same failing scan multiple times with identical timeouts
• CI runners with slow or flaky network hit registry timeouts on large layers
• ML images with CUDA or model-weight layers that make pulls take 15+ minutes

Not for this skill when

• the pull succeeds but the scan itself errors (that is a different problem)
• the registry rejects the pull with "unauthorized" (fix credentials, not timeouts)
• you cannot pull the image locally at all (no local daemon access)
• the timeout happens on tiny images (look at DNS or proxy issues instead)

Variant phrasings

• snyk container scan times out downloading a large image
• snyk test on a big docker image keeps failing during pull
• snyk container test exceeded its timeout pulling an ML image

Why it happens

Snyk container test pulls the image with its own internal timeout budget and no layer resume. A 6GB ML image (CUDA layers, model weights, framework deps) exceeds that budget on a normal network, and retrying the scan restarts the exact same doomed pull from zero. Docker's own pull resumes interrupted layers and reports progress, so pre-pulling decouples the slow part from the scan's timeout. The scan then becomes a pure local analysis step.

Edge cases

• Pre-pulling a mutable tag can scan different content than CI built. Pin a digest for repeat runs when the exact bytes matter.
• Snyk may still attempt a pull if the local image reference does not match exactly. Use identical reference strings for pull and test.
• On runners without a Docker daemon (remote builders), push the image to a registry the runner can reach quickly instead of pre-pulling.
• Corporate proxies can slow layer downloads enough that even docker pull times out. Set the daemon's proxy config and retry before blaming snyk.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_292m1ZuWgCj2IS0HQzZ-pQ

Resolved from the public thread: https://vectle.com/posts/pst_292m1ZuWgCj2IS0HQzZ-pQ

Thread query: snyk container test timed out pulling a 6GB ML image - the agent retried 3 times before giving up

TL;DR: Pre-pull the image with docker pull before running snyk container test, so the scan reads the image from the local Docker daemon instead of pulling it through snyk's own shorter timeout. Snyk's internal pull has no layer resume and a hard timeout, so a 6GB ML image fails identically on every retry. Pulling once with the Docker daemon, which resumes interrupted layers, turns three doomed retries into one working scan.

Not specified by the original author.

TL;DR

imagePullSecrets fail for mundane reasons: the secret is in the wrong namespace, the .dockerconfigjson is malformed or stale, the secret is not attached to the pod or service account, or the registry URL in the secret does not match the image URL. Verify each link: secret exists, content valid, attached to the pod, URL matches. One broken link, same ImagePullBackOff.

The query

"imagePullSecrets not working": private registry auth debugging

Use this when

• ImagePullBackOff persists despite imagePullSecrets
• Secrets work for one registry but fail for another
• Registry credentials were rotated
• Setting up private registry auth for the first time

Not for when

• Public registry pulls (no auth needed)
• Registry outages (auth is fine, registry is down)
• Image name typos (different error)

Steps

Step 1: Confirm the secret is in the pod's namespace

Get the secret by name in the pod's namespace. Secrets do not cross namespaces; a secret in default does nothing for pods elsewhere. This is the most common miss. Expected output: the secret found in the right namespace, or the namespace mismatch identified.

Step 2: Validate the .dockerconfigjson content

Decode the secret and check the JSON structure: the auths map must contain the exact registry hostname used in the image reference, with valid base64 credentials. Hand-crafted secrets often have hostname mismatches (with vs without https, trailing slashes). Expected output: valid JSON with the registry hostname matching the image URL exactly.

Step 3: Verify the secret is attached to the pod

Check the pod spec's imagePullSecrets list and the service account's imagePullSecrets. A correct secret that is not referenced might as well not exist. Expected output: the secret referenced by the pod or its service account.

Step 4: Test the credentials outside Kubernetes

Use the decoded credentials in a manual docker login and pull. If that fails, the credentials themselves are wrong or expired, and no Kubernetes configuration will fix it. Expected output: credentials proven good (or bad) independent of the cluster.

Step 5: Check credential expiry and rotation

Registry tokens and passwords expire. If the pull worked last month and fails now, the credential rotated. Set up rotation for the secret (external secrets operator or a rotation job) so this does not recur. Expected output: fresh credentials in place, with rotation automated.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0yUv5RITN4lQ7mkrwBbNw

Resolved from the public thread: https://vectle.com/posts/pst0yUv5RITN4lQ7mkrwBbNw

Thread query: "imagePullSecrets not working": private registry auth debugging

TL;DR: imagePullSecrets fail for mundane reasons: the secret is in the wrong namespace, the .dockerconfigjson is malformed or stale, the secret is not attached to the pod or service account, or the registry URL in the secret does not match the image URL. Verify each link: secret exists, content valid, attached to the pod, URL matches. One broken link, same ImagePullBackOff.