-
Notifications
You must be signed in to change notification settings - Fork 531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cosign sign does not use local image registry credentials #587
Comments
What if you leave off the "docker.io"? cc @jonjohnsonjr any ideas here? |
Can you share this file (with anything sensitive redacted)? |
Looks like a pretty standard dockerconfigjson:
|
Same result. |
Note for quay.io authentication isn't the issue - cosign is able to log in just fine, however uploading signatures fails because quay.io doesn't accept the cosign layer type. See log: https://gist.github.com/adambkaplan/0b8b4bfdaf8771d57730eface258d5a8 |
It's stupid but can you try changing the Some version of docker would set this as the key, and I haven't found a reasonable way to work around this without breaking someone: https://github.com/docker/cli/blob/25eee83d6b8c475548254b2decc9c8e0490d229c/cli/config/configfile/file.go#L23 |
Sadly same result 😞 |
Hm. You're right, it's not sending creds in the initial auth handshake. I would have guessed that Looks like ggcr does recognize |
😭 You're certain you don't have a credential store or credential helper configured? https://docs.docker.com/engine/reference/commandline/login/#credentials-store
This would match the failure mode I expect from your config file :/ |
I am running Fedora 34 Silverblue - no credential store as far as I am aware of, and assuming the presence of anything Docker is not a safe assumption! |
I don't want to say I don't believe you, but I'm having a hard time imagining what could be going wrong here 😄 Can you verify that cosign is reading the right file (via Are you executing cosign as a different user, maybe? Is |
I can verify it is reading what I think is the right file. From strace, it's clear the config.json file is read:
I'm running cosign in a Silverblue toolbox. It's a container-like environment where the user looks and feels the same as the user on the host system. So in the toolbox I'm my normal username with my normal permissions.
No - this is empty. |
So I know that podman tries to read a different file by default from here:
Are you certain that podman is reading the same credentials file as It's possible that fixing this issue gets you some credentials, but not valid credentials? In your original debug logs, we see that cosign isn't sending any credentials to Docker Hub:
If we're sending invalid credentials, we would expect to see this line as well:
|
@jonjohnsonjr it seems the root issue here is that it is very hard to identify which credentials are being used to push/pull from the container registry. Next chance I have some free "hacking" time I can try submitting a PR to surface this in debug logs. Any initial guidance/pointers would be appreciated - thanks! |
I'm hitting this same issue when trying to integrate cosign into our teams CI flow. Any use of buildah, podman, skopeo based tools where the credentials are stored in a different location than ~/.docker, seems to have cosign not recognise the use of a different container build tool and it's already authenticated information creds. As these tools are commonly used in automated flows, it would be great if anyone has any ideas to work round the current situation. |
I skimmed the issue but had issues (403) I'm running Docker under a Snap (I assume I'll have the same issue w/ e.g. Podman) and the Snap maintains The solution was to copy (I guess I could have I assume the issue is that I think it would be preferable either to be able to configure |
Not a daemon, just the normal docker config file behavior; i.e.
There's not really a registry API for logging in. We could support a I think the cosign tool and docs could probably do a better job describing how auth works, regardless. |
Veto :p We should endeavor to figure out @adambkaplan's issue and identify how we've differed from Docker's credential resolution behavior. I might have volunteered myself for that 😢
Agreed. |
@tommyreilly you're right, it only supports If we end up supporting some alternative to Docker's configuration and authentication scheme, it should be one we maintain. I think documenting our |
Hi, had auth issues (I use podman instead of docker), the following was a workaround for me:
|
My two cents:
I found out that if the registry URL is |
Sadly, I'm expirencing the same issue as others.
Output of Docker's
Podman's
Any ideas? |
You're certain the credentials are valid? |
Since google/go-containerregistry#1185 which should be in cosign afaik, cosign will check for podman's auth config as well. Does this help at all? |
Didn't see your response till now, sorry. Yes, credentials are fine, push/pulls against the registry function normally. This is my own local instance. I'll try again with a new release. |
In my case, I discovered that this .docker/config.json results in authentication failure:
But this one results in success:
Interestingly the authentication failure when
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
working as expected , great 👍 |
can't cosign look in the default credentials location for both podman and docker? |
In some CI/CD, if you need run cosign in buildah container with docker or podman, you must exec |
Question
I'm trying to sign a container image that I pushed to docker.io. This seems simple enough:
However, when trying to pull the image, cosign does not appear to use my local credentials. Instead cosign appears to do the following:
I was able to verify that my ~/.docker/config.json contains valid auth credentials for docker.io, and that I can pull images using those credentials with my container engine (podman).
This could be related to #337.
Here's the debug output:
The text was updated successfully, but these errors were encountered: