sigstore / cosign

Code signing and transparency for containers and binaries
Apache License 2.0
4.36k stars 531 forks source link

`cosign attach` commands support providing a signature or attestation but not certificate #2267

Open znewman01 opened 1 year ago

znewman01 commented 1 year ago
$ cosign attach -h
Provides utilities for attaching artifacts to other artifacts in a registry

Usage:
  cosign attach [command]

Available Commands:
  attestation Attach attestation to the supplied container image
  sbom        Attach sbom to the supplied container image
  signature   Attach signatures to the supplied container image

[...]

Use "cosign attach [command] --help" for more information about a command.

If you attach a signature:

cosign attach signature -h
Attach signatures to the supplied container image

Usage:
  cosign attach signature [flags]

Examples:
  cosign attach signature <image uri>

Flags:
      --allow-insecure-registry                                                                  whether to allow insecure connections to registries. Don't use this for anything but testing
      --attachment-tag-prefix [AttachmentTagPrefix]sha256-[TargetImageDigest].[AttachmentName]   optional custom prefix to use for attached image tags. Attachment images are tagged as: [AttachmentTagPrefix]sha256-[TargetImageDigest].[AttachmentName]
  -h, --help                                                                                     help for signature
      --k8s-keychain                                                                             whether to use the kubernetes keychain instead of the default keychain (supports workload identity).
      --payload string                                                                           path to the payload covered by the signature (if using another format)
      --signature string                                                                         the signature, path to the signature, or {-} for stdin

[...]

There's no way to put a signature and accompanying certificate on the image.

znewman01 commented 1 year ago

When we do this, we need to make sure that the verify commands can also use the attached certificate!

hectorj2f commented 1 year ago

@znewman01 What do we want to verify for the certificate ? Should we expect any precedence over other verifications ?

znewman01 commented 1 year ago

The overall workflow for external signing using a CA before the feature requested in this issue.

  1. There's a root cert R.
  2. Get a child cert C with keys pk and sk.
  3. Sign the image payload P with sk to get a signature S.
  4. cosign attach S and P to the image in the registry.
  5. Distribute R and C out-of-band.

To verify, you run something like cosign verify --root R --certificate C --certificate-identity user@example.com --certificate-issuer accounts.example.com and S and P are auto-discovered from the OCI registry.

The proposal here is to just stick C in the OCI registry and allow it to be auto-discovered as well. I think the verification piece will "just work" if we stick C in the "signature" object, which is how certs are distributed for keyless signing.

zoltani commented 1 year ago

@znewman01 Here actually C should be a cert chain, not a single cert. There is no guarantee that C (if just a leave cert), is signed by R. So ideally the verify command should look like this: cosign verify --root R. And everything else (C (chain), S, P) can be auto discovered from OCI registry.

Also for the root R the underlying system's PKI path can be used.

And the admission controller should work on a similar way. Getting the accepted root CA certs from a pre-defined location/set, and everything else from the OCI registry.

znewman01 commented 1 year ago

@znewman01 Here actually C should be a cert chain, not a single cert. There is no guarantee that C (if just a leave cert), is signed by R. So ideally the verify command should look like this: cosign verify --root R. And everything else (C (chain), S, P) can be auto discovered from OCI registry.

Yeah, I think that's reasonable. Fortunately I think it's compatible with everything else.

Also for the root R the underlying system's PKI path can be used.

I would like that to be opt-in behavior; I think it's somewhat surprising if you don't explicitly want it. But again something you'd want in certain cases

And the admission controller should work on a similar way. Getting the accepted root CA certs from a pre-defined location/set, and everything else from the OCI registry.

Seems like a good idea.

Mukuls77 commented 1 year ago

I have created a Pull request https://github.com/sigstore/cosign/pull/2602 To provide changes required for the enhancement needed in Attach and Verify command. Kindly review the Pull request