Does cosign supports signing of local images ?

[shimish2]

Question
Does cosign supports signing of local images ?

I am trying to sign a local image but getting this error

cosign sign --key /tmp/cosign/cosign.key /tmp/cosign-test:1.0.0 
error: signing /tmp/cosign-test:1.0.0: getting remote image: GET https://index.docker.io/v2/tmp/cosign-test/manifests/1.0.0: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:tmp/cosign-test Type:repository]]

[dlorenc]

Hey!

Unfortunately we don't support this today, you can see some of the discussion over at #60. There are a lot of caveats involved in the way digests get calculated with a local docker daemon - the digest might not even exist.

What's the overall flow you're trying to achieve? There might be other ways to do it.

[shimish2]

It's a normal flow as same as remote image, able to sign & verify locally and by local I mean local oci images.

[dekkagaijin]

As @dlorenc said, the thing being signed (the image manifest) doesn't get created until an image is pushed to a repo and doesn't generally get persisted on image pulls. It's not clear how the UX for signing or verifying local images would work

[sudo-bmitch]

I'm thinking through a similar workflow. The build pipeline may be performed in a disconnected environment without access to a registry or the general internet. The output of the container image build could be an OCI Layout tar file that includes an index.json that has the descriptor of the image that would be pushed to the registry. If there's a way to sign a digest without pushing the result, just generating another OCI Layout tar that contains a signature, that would be the ideal scenario, but I'd settle for a signature. Then at the end of the build when the image and signature have been generated, they can be uploaded to a registry.

@dlorenc would it be enough to accept an image reference with a digest (vs a tag) without querying a registry to lookup that digest? I think some logic would need to be moved around for the recursive handling of an Index, but seems like it should be feasible.

[dlorenc]

@dlorenc would it be enough to accept an image reference with a digest (vs a tag) without querying a registry to lookup that digest? I think some logic would need to be moved around for the recursive handling of an Index, but seems like it should be feasible.

+1, yeah I don't see any issues there.

[dmesser]

I tried using #903 but it doesn't work for me. Even though the digest is correct, cosign will try to reach the registry where the image is stored.

The use case here is zero-trust in the registry. Currently I have to have some trust in the registry that it doesn't mingle with my content after I pushed it but before I signed it.

[sudo-bmitch]

If you have the digest, and you're signing that, then you have zero trust in the registry. The registry can't change the content without changing the digest.

[dmesser]

@sudo-bmitch Agreed, but I couldn't get cosign to sign without trying to contact the registry which I understand your PR would enable. Maybe I had wrong expectations?

[sudo-bmitch]

@dmesser best guess is something changed to sign the entire descriptor and a digest isn't enough. The fix for that would be using an OCI Layout. But the underlying problem you wanted to solve shouldn't be an issue.

[dmesser]

Is using an OCI layout referring to an on-disk representation where I can direct cosign sign to an image URI starting with oci:// or to an OCI image stored in a registry?

[sudo-bmitch]

It's referring to the on-disk format. There's still a lot to develop for this (not just in cosign), and you'd need a separate step to copy the signed image to a registry later. I was talking about this at Open Source Summit this year showing a lot of the gaps left to be resolved, and why we should want to solve them.
https://sudo-bmitch.github.io/presentations/oci-layout/presentation.html#2

[github-actions]

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.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.