-
Notifications
You must be signed in to change notification settings - Fork 779
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
copy: consider support cosign: verify image while pulling from source & sign image while copying to destination #1533
Comments
Thanks for your report. Most of that infrastructure needs to be developed in containers/image (and in particular, the public keys or other roots of trust need to be configured in For reference, some very partial work on that has happened in containers/image#1364 . |
A friendly reminder that this issue had no activity for 30 days. |
A friendly reminder that this issue had no activity for 30 days. |
@mtrmac and I are currently working on integrating cosign into the toolchain. |
that's awesome, please let us know if anything we can help 🙋🏻♂️ |
@vrothberg @mtrmac, is there anything that we might get involved in it? We're willing to work on this 🤩 |
Thanks for offering help, @developer-guy, much appreciated! At the time of writing, I don't see any work items that we can distribute. We are currently consolidating parts of sigstore/cosign into sigstore/sigstore; the cosign code entails a lot dependencies that we need to prune. |
A friendly reminder that this issue had no activity for 30 days. |
A friendly reminder that this issue had no activity for 30 days. |
Maybe we can just do call cosign binary directly instead of bring it as a new dependency. |
I don't think that is sustainable solution long term. The binary size of Skopeo is currently ~20MB, Cosign is currently at ~90MB. Cosign can do much more than just signing and verifying images. |
Dropping Sanitize cosign's dependency tree issue as a reference. |
A friendly reminder that this issue had no activity for 30 days. |
@Dentrax As a side, what's the perceived value of signing something while copying? Wouldn't you rather want to copy images that are signed already, verifying and copying the signature with the image in the process? See containers/image#1575 It seems like the assumption here is that we want to establish trust on a copy operation. Talking to users and customers taught me that they don't want to trust the machine / registry that's doing the copy but rather the source. Establishing a supply chain security posture that they can attest to along the pipeline. |
To update the status, as of #1701 and the just-released Skopeo 1.9.0, Skopeo can enforce signatures via |
A typical use case is promotion from a testing build to an approved public release:
Alternatively, some large companies like to have an internal “use in $company is approved” signature added to every third-party image, and enforce their presence. |
Yes, this is the idea, but also I see the your concern in next statement:
Miloslav already covers the exact use-case and why we need:
Definitely what we were looking for! I tried the new v1.9.0 release and couldn't make it work in the first place and filed an issue: containers/image#1613 After played a while, I am finally figured it out and make it work! This feature is exactly why we filed this issue is for. I think we can close this one. 👏 |
If you don’t mind, I’d like to keep this open to track the planned Fulcio/Rekor support/interoperability. (Compare also #1704 .) |
And users are looking to do that all with a tool that actually copies images? Seems like scope creep to me. Validating signatures as part of copying makes a lot of sense. Signing not so much (IMHO). Users will likely want to use a specific signing tool (cosgin, podman).
That makes sense, but again, why would someone do that with skopeo as part of the copy? Chances are that the decision whether to bless something with a company signature is based on some introspection, so the process likely involves downloading the image first and doing something with it. It's very likely that the user wants to sign the image in a specific way, which requires |
I mean, what other tool in the GitHub.com/containers ecosystem would be more appropriate? The “promotion of a testing build” use case is literally copying an unmodified image from an internal testing repo to the public repo, which is the primary job of (Users that don’t have a testing repo and just want build and publish an image would not need Skopeo; they can just I could totally buy an argument that this should be an integrated part of a large-scale build system application, and such an application should not shell out to a separate CLI. That’s perfectly fine; Skopeo is a thin wrapper over c/image and to an extent intentionally an example for building such large applications.
In contrast,
(I’m skeptical that an introspection of a few hundreds of megabytes of binary code can actually ensure much about the behavior, but sure, it can help with checking boxes like “Was this built in one of a $dozen approved systems? Are all the RPMs upgraded as of today?”. In my thinking, an introspection of an already-built image is a distinct second best to enforcing policy, and signing, as an integral part of a build pipeline.) That said, for an introspection workflow,
And again, this could certainly be an integrated part of a larger application that calls a Go library, not necessarily invoking the
The set of features is definitely going to be limited to something we can understand, maintain, test against, and support. Other use cases are going to be better served with specialized tools, maybe built on top of c/image, maybe on top of |
Calling cosign binary right after copy of an image, leads to a slight time window in which it could have tampered. I think signing should be inherent to the image copy process. One use-case example is that companies runs tons of images in the production. If you want to enforce signed image policy in your clusters using a Policy Engine, you have to find all the public keys to verify against with. Instead we could mark the image simply one signature to ensure: "yes, we copied that image and validated it's signature, we trust this image to run in clusters. (Its could be scanned, audited, etc.)
I completely understand the concern here. We don't want to make |
I get the argument that currently the gap in In your example @mtrmac you speak about an internal testing repo. So @Dentrax This interesting, because I heard exactly the opposite. In a zero-trust environment customers don't want to trust the machine that does the copy. They want all the images to be signed by the vendor already and trust the vendors keys for full end2end accountability and integrity. I think cosign's effort to move towards OIDC identity based trust |
That’s just not how it works in the GitHub.com/containers ecosystem. Locally-built images in c/storage don’t have a compressed representation that can be signed and then pushed; they are compressed during the push, and that’s the earliest reasonable time to sign them (before that, an uncompressed representation would be signed, and it would have to also be published uncompressed in order not to break the signature). Sure, there’s some nuance to this (a single-purpose local registry, or pushing to a staging
(Again, I expect the majority of users to rely on Podman rather than Skopeo, which makes all this focus on Skopeo a bit surprising.)
*shrug* The software exists. I don’t see arguing now that it shouldn’t have been written as all that productive.
Specific RFEs and pointing out functionality that is critical to support (both for signing and verification) could be useful (in separate issues, in the c/image/ repo, please). “This feature shouldn’t exist” is much less so. |
|
To be honest I didn't know that skopeo had the For what it's worth, since |
Thanks, that’s actually a good point: the c/image/docker destination implementation does write the manifest before the signatures, so there is a time where the image is visible on the destination unsigned. But that’s not actually inherent to the design, let’s track fixing it in containers/image#1623 . |
The last update for this issue is #1533 (comment) . |
A friendly reminder that this issue had no activity for 30 days. |
Skopeo 1.11 now supports
That’s about as far as I currently want to take this; any future enhancements would depend on user feedback and production experience. (#1704 is still mostly outstanding.) |
Currently, we can pass a
--sign-by
flag by giving a GPG key.Just thinking how cosign fit in this project, so drew the following architecture:
We probably have to introduce some new flags to achieve this goal:
Eventually, the final
copy
command will look like this:It's optional to sign the image again with a different key. The motivation behind this is we might want to ensure all the images are signed with our own private key in the internal registry. So we can easily validate it before the deployment.
Any thoughts?
cc @developer-guy @dlorenc
The text was updated successfully, but these errors were encountered: