-
Notifications
You must be signed in to change notification settings - Fork 537
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
Add sign --sign-container-identity
CLI
#2984
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2984 +/- ##
==========================================
+ Coverage 30.45% 30.96% +0.51%
==========================================
Files 152 153 +1
Lines 9586 9676 +90
==========================================
+ Hits 2919 2996 +77
- Misses 6210 6222 +12
- Partials 457 458 +1
|
692f5ff
to
8f3c197
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly support this feature; it is necessary not only for proxies, but also for many staging workflows (creating an image signed with the production key, with a production identity, but not publishing it yet and storing it in an internal registry).
cmd/cosign/cli/options/sign.go
Outdated
@@ -108,4 +109,7 @@ func (o *SignOptions) AddFlags(cmd *cobra.Command) { | |||
|
|||
cmd.Flags().BoolVar(&o.IssueCertificate, "issue-certificate", false, | |||
"issue a code signing certificate from Fulcio, even if a key is provided") | |||
|
|||
cmd.Flags().StringVar(&o.DockerReference, "docker-reference", "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skopeo names this parameter --sign-identity
, and I think that captures the intent a bit more accurately; both in being more explicit about what the field means, and in not referring to a specific implementation. (The “simple signing” JSON payload field name should be viewed as a historical artifact.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also happy with --sign-identity
, what do the other maintainers think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s a little confusing to reuse identity, since we use identity already to refer to who is doing the signing. Maybe sign-container-identity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @haydentherapper here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to --sign-container-identity
naming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
we just need to remove the replace when the PR from sigstore/sigstore is merged
06e3f22
to
d6db445
Compare
sign --docker-reference
CLIsign --sign-identity
CLI
d6db445
to
4ab770c
Compare
sign --sign-identity
CLIsign --sign-identity
CLI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks for the change.
I see there's a little bit of worry about the flag name. I'm empathetic: it's a little weird to say the image has an identity, especially when there's also a signer identity in play.
I don't want to bikeshed too much further, but maybe the name is a little less important if we can make the help text a bit more explicit and to add an example to the cosign sign
docs.
My way too wordy version, written to check my own understanding here, would be:
cosign sign
uses the "simple signing" format for signatures, which links an image with a given digest to adocker-reference
: basically, "imagesha256@...
isalpine:latest
." By default, we infer the docker reference based on what you sign; this flag allows you to override that (for instance, to specify a tag instead of a digest, or when using a proxy).
Maybe something like:
--sign-identity
: claim that the image being signed has the given identity (instead of inferring this from the provided image identifier): signmy-registry.io/foo@sha256:...
asmy-registry.io/foo:v1
or evenother-registry.io/bar:latest
.
And then add an example like:
# sign a container image, identifying it by tag
cosign sign --sign-identity registry.io/foo:latest my-proxy.io/foo@sha256:abcdef
# sign a container image fetched via a proxy, identifying it by the upstream Docker reference.
cosign sign --sign-identity upstream-registry.io/foo:latest my-proxy.io/foo@sha256:abcdef
Feel free to revise any of the above. But I think if the docs are really clear we can live with an imperfect name.
(This suggests that maybe we eventually want some sugar we'd want for using a tag as the --sign-identity
: maybe --sign-identity :tag
. But we can deal with that later).
All of the above makes sense to me. For a bit more context to consider, separately from his PR, I’d afterwards like to replace/discourage the currently-recommended I’m a bit struggling with a good UI… one alternative is to make the $ cosign sign --sign-identity registry.io/foo:latest my-proxy.io/foo@sha256:abcdef My preference would be, instead, to add yet another option: $ cosign sign --digest sha256:abcdef registry.io/foo:latest because that can be built “naturally”: a naive user says That would be an alternative for adding the |
All SGTM. I think this PR represents a great first step in that direction. |
I also find confusing a lot this flag |
4ab770c
to
e626d60
Compare
sign --sign-identity
CLIsign --sign-identity
CLI
sign --sign-identity
CLIsign --sign-identity
CLI
e626d60
to
ef9b104
Compare
sign --sign-identity
CLIsign --sign-container-identity
CLI
ef9b104
to
99a6f01
Compare
Switched to |
99a6f01
to
caa1494
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm happy modulo the request for additional examples in the docs (and maybe a slightly longer flag description)!
The `--sign-container-identity` flag allows setting the `critical.identity.docker-reference` field in the signature to a different container image reference. This is particularly useful when using proxy mirrors like `registry.k8s.io`, where end-users have no chance to actually assume the underlying registry. This change allows signing images using the mirror/proxy identifier, while validation can then happen without requiring any additional remapping. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
caa1494
to
5aac8e4
Compare
After the merge of sigstore/cosign#2984, we now can use the new option to support it within the release-sdk as well. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
After the merge of sigstore/cosign#2984, we now can use the new option to support it within the release-sdk as well. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
After the merge of sigstore/cosign#2984, we now can use the new option to support it within the release-sdk as well. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Summary
The
--sign-container-identity
flag allows setting thecritical.identity.docker-reference
field in the signature to a different container image reference. This is particularly useful when using proxy mirrors likeregistry.k8s.io
, where end-users have no chance to actually assume the underlying registry. This change allows signing images using the mirror/proxy identifier, while validation can then happen without requiring any additional remapping.Refers to containers/image#1952, sigstore/sigstore#1166
Release Note
Added
sign --sign-identity
CLI flag.Documentation
TBD.