From af9961cfc1f0154dba91366469c771e090cd172a Mon Sep 17 00:00:00 2001 From: Zach Steindler Date: Fri, 6 Mar 2026 11:37:12 -0500 Subject: [PATCH 1/4] Updating cosign signing docs Signed-off-by: Zach Steindler --- content/en/cosign/signing/git_support.md | 8 +- content/en/cosign/signing/gitsign.md | 261 ------------------ content/en/cosign/signing/other_types.md | 219 +-------------- content/en/cosign/signing/overview.md | 17 +- .../en/cosign/signing/signing_with_blobs.md | 75 +---- .../cosign/signing/signing_with_containers.md | 254 ++--------------- 6 files changed, 57 insertions(+), 777 deletions(-) delete mode 100644 content/en/cosign/signing/gitsign.md diff --git a/content/en/cosign/signing/git_support.md b/content/en/cosign/signing/git_support.md index a56b7a89..09f31dc2 100644 --- a/content/en/cosign/signing/git_support.md +++ b/content/en/cosign/signing/git_support.md @@ -23,14 +23,14 @@ To generate keys using a Git provider, you can use the `cosign generate-key-pair argument `github://` or `gitlab://`. For example: ```shell -cosign generate-key-pair :/// +$ cosign generate-key-pair :/// ``` One little note here, if you prefer to use GitLab as a provider, you can specify the `ID` of the project instead of its name and owner, for example: ```shell -cosign generate-key-pair gitlab:// +$ cosign generate-key-pair gitlab:// ``` The public key can be retrieved with: @@ -78,6 +78,6 @@ feature is only available to GitLab. GitHub does not support it to fetch the sec You can also export the public key and verify it against that file: ```shell -cosign public-key --key gitlab:/// > gitlab.pub -cosign verify --key gitlab.pub gcr.io/user-vmtest2/demo +$ cosign public-key --key gitlab:/// > gitlab.pub +$ cosign verify --key gitlab.pub gcr.io/user-vmtest2/demo ``` diff --git a/content/en/cosign/signing/gitsign.md b/content/en/cosign/signing/gitsign.md deleted file mode 100644 index 893ebfc8..00000000 --- a/content/en/cosign/signing/gitsign.md +++ /dev/null @@ -1,261 +0,0 @@ ---- -type: docs -category: Signing -menuTitle: Signing Git Commits -title: Gitsign -weight: 134 ---- - -![Gitsign Overview](/sigstore_gitsign-horizontal-color.svg) - -Gitsign implements keyless Sigstore to sign Git commits with a valid -[OpenID Connect](https://openid.net/connect/) identity. In practice, that means -you won’t need GPG keys and a complicated setup in order to sign your Git -commits. After installing and configuring Gitsign within your project and -signing your commits, you will be redirected to a browser window to authenticate -with a supported OpenID provider, such as GitHub or Google. Signing details will -then be stored in the transparency log [Rekor]({{< relref "logging/overview">}}) for subsequent verification. - -Gitsign is part of the Sigstore project. Join us on our -[Slack channel](https://sigstore.slack.com/) if you want to learn more or get -involved. Join our Slack channel with -[this invite](https://links.sigstore.dev/slack-invite). - -## Quick Start - -Gitsign can be installed via the Go installer, with Homebrew, or with one of the -package installers available on the project -[releases page](https://github.com/sigstore/gitsign/releases). These include -`.deb` and `.rpm` formats for Debian and Fedora systems, respectively. Check the -installing Gitsign section below for more details on how to get -Gitsign installed on your system. - -Once configured, you can sign commits as usual with `git commit -S` (or -`git config --global commit.gpgsign true` to enable signing for all commits). - -```sh -$ git commit -Your browser will now be opened to: -https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&... -[main 040b9af] Signed commit -``` - -This will redirect you through the [Sigstore Keyless]({{< relref "cosign/signing/overview">}}) -flow to authenticate and sign the commit. - -Commits can then be verified using `git verify-commit`: - -```sh -$ git verify-commit HEAD -tlog index: 2801760 -gitsign: Signature made using certificate ID 0xf805288664f2e851dcb34e6a03b1a5232eb574ae | CN=sigstore-intermediate,O=sigstore.dev -gitsign: Good signature from [billy@chainguard.dev] -Validated Git signature: true -Validated Rekor entry: true -``` - -## Installing Gitsign - -You can install Gitsign on your system with the Go installer, via Homebrew, or -with one of the available downloadable packages. Releases are published in -[the Gitsign repository](https://github.com/sigstore/gitsign) under the -[Releases page](https://github.com/sigstore/gitsign/releases). - -### Installing Gitsign with Go 1.17+ - -If you have [Go 1.17+](https://go.dev/doc/install), you can install Gitsign with: - -```console -go install github.com/sigstore/gitsign@latest -``` - -The resulting binary will be placed at `$GOPATH/bin/gitsign`. - -### Installing Gitsign with Homebrew - -If you are using [Homebrew](https://docs.brew.sh/) as a package manager for -macOS or Linux, you can use it to install Gitsign. Use `brew tap` to add -Sigstore's repository to your system, then run `brew install` to get it -installed: - -```console -brew tap sigstore/tap -brew install gitsign -``` - -### Installing Gitsign with the `.deb` Package (Debian / Ubuntu Linux) - -gitsign is now available in development releases of Debian and Ubuntu, and should be available to `apt install` starting with Ubuntu 25.04 ('plucky') and Debian ('trixie'). - -Meanwhile, you can check the [releases page](https://github.com/sigstore/gitsign/releases) for the -latest release, and download the appropriate `.deb` file. - -```console -wget https://github.com/sigstore/gitsign/releases/download/v/gitsign__linux_amd64.deb -sudo dpkg -i gitsign__linux_amd64.deb -``` - -### Installing Gitsign with the `.rpm` Package (Fedora Linux) - -Check the [releases page](https://github.com/sigstore/cosign/releases) for the -latest release, and download the appropriate `.rpm` file. - -```console -wget https://github.com/sigstore/gitsign/releases/download/v/gitsign__linux_amd64.rpm -rpm -ivh gitsign__linux_amd64.rpm -``` - -## Checking your Installation - -Once you finish installing Gitsign, you can test that it is functional and -ensure that it can be found on your $PATH by running a `gitsign` command. - -```shell -$ gitsign --version -gitsign version v0.7.1 -``` - -### Troubleshooting - -If you get an error such as `command not found`, it may be the case that your -`$PATH` does not include the relevant bin directories where Gitsign should be -installed. - -If you installed Gitsign with Go, make sure you have your Go bin directory added -to your `$PATH`. - -## Configuring Git to use Gitsign - -After installing Gitsign on your system and making sure it is functional, you’ll -need to tell Git that you want to use Gitsign to sign your commits from now on, -whether locally on a project-based configuration or globally, which will be -valid for commits made from your current system to any project. - -### Single Repository (Local Config): - -```sh -cd /path/to/my/repository -git config --local commit.gpgsign true # Sign all commits -git config --local tag.gpgsign true # Sign all tags -git config --local gpg.x509.program gitsign # Use Gitsign for signing -git config --local gpg.format x509 # Gitsign expects x509 args -``` - -### All Repositories (Global Config): - -```sh -git config --global commit.gpgsign true # Sign all commits -git config --global tag.gpgsign true # Sign all tags -git config --global gpg.x509.program gitsign # Use Gitsign for signing -git config --global gpg.format x509 # Gitsign expects x509 args -``` - -## Configuration - -### File config - -Gitsign can be configured with a standard -[git-config](https://git-scm.com/docs/git-config) file. For example, to set the -Fulcio option for a single repo: - -```sh -$ git config --local gitsign.connectorID https://accounts.google.com -$ cat .git/config -[gitsign] - connectorID = https://accounts.google.com -``` - -The following config options are supported: - -| Option | Default | Description | -| ----------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| fulcio | https://fulcio.sigstore.dev | Address of Fulcio server | -| logPath | | Path to log status output. Helpful for debugging when no TTY is available in the environment. | -| clientID | sigstore | OIDC client ID for application | -| issuer | https://oauth2.sigstore.dev/auth | OIDC provider to be used to issue ID token | -| redirectURL | | OIDC Redirect URL | -| rekor | https://rekor.sigstore.dev | Address of Rekor server | -| connectorID | | Optional Connector ID to auto-select to pre-select auth flow to use. For the public sigstore instance, valid values are:
- `https://github.com/login/oauth`
- `https://accounts.google.com`
- `https://login.microsoftonline.com` | - -### Environment Variables - -| Environment Variable | Sigstore
Prefix | Default | Description | -| ------------------------- | ------------------ | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| GITSIGN_CREDENTIAL_CACHE | ❌ | | Optional path to [gitsign-credential-cache](https://github.com/sigstore/gitsign/tree/main/cmd/gitsign-credential-cache) socket. | -| GITSIGN_CONNECTOR_ID | ✅ | | Optional Connector ID to auto-select to pre-select auth flow to use. For the public Sigstore instance, valid values are:
- `https://github.com/login/oauth`
- `https://accounts.google.com`
- `https://login.microsoftonline.com` | -| GITSIGN_FULCIO_URL | ✅ | https://fulcio.sigstore.dev | Address of Fulcio server | -| GITSIGN_LOG | ❌ | | Path to log status output. Helpful for debugging when no TTY is available in the environment. | -| GITSIGN_OIDC_CLIENT_ID | ✅ | sigstore | OIDC client ID for application | -| GITSIGN_OIDC_ISSUER | ✅ | https://oauth2.sigstore.dev/auth | OIDC provider to be used to issue ID token | -| GITSIGN_OIDC_REDIRECT_URL | ✅ | | OIDC Redirect URL | -| GITSIGN_REKOR_URL | ✅ | https://rekor.sigstore.dev | Address of Rekor server | - -For environment variables that support `Sigstore Prefix`, the values may be -provided with either a `GITSIGN_` or `SIGSTORE_` prefix - e.g. -`GITSIGN_CONNECTOR_ID` or `SIGSTORE_CONNECTOR_ID`. If both environment variables -are set, `GITSIGN_` prefix takes priority. - -## Signing a Commit - -After installing Gitsign and configuring Git to use it as a signer application -for your project (or globally), you can sign commits as usual with -`git commit -S` (or `git config --global commit.gpgsign true` to enable signing -for all commits). - -```sh -$ git commit --message="Signed commit" -Your browser will now be opened to: -https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&... -[main 040b9af] Signed commit -``` - -Commits can then be verified using `git verify-commit`: - -```sh -$ git verify-commit HEAD -tlog index: 2801760 -gitsign: Signature made using certificate ID 0xf805288664f2e851dcb34e6a03b1a5232eb574ae | CN=sigstore-intermediate,O=sigstore.dev -gitsign: Good signature from [billy@chainguard.dev] -Validated Git signature: true -Validated Rekor entry: true -``` - -## Signing Tags - -You can sign tags with `git tag -s` (or `git config --global tag.gpgsign true` -to enable signing for all tags). - -```sh -$ git tag v0.0.1 -Your browser will now be opened to: -https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&... -``` - -This will redirect you through the Sigstore Keyless flow to authenticate and -sign the tag. - -Tags can then be verified using `git verify-tag`: - -```sh -$ git verify-tag v0.0.1 -tlog index: 2802961 -gitsign: Signature made using certificate ID 0xe56a5a962ed59f9e3730d6696137eceb8b4ee8ea | CN=sigstore-intermediate,O=sigstore.dev -gitsign: Good signature from [billy@chainguard.dev] -Validated Git signature: true -Validated Rekor entry: true -``` - -## Debugging - -If there is a problem during signing, you may receive an error similar to the -following: - -``` -error: gpg failed to sign the data -fatal: failed to write commit object -``` - -By default, gitsign will try and write to your terminal if there is a TTY -available. If you are running in an environment where there is not a TTY, you -can use the `GITSIGN_LOG` environment variable to tee logs into a readable -location for debugging. diff --git a/content/en/cosign/signing/other_types.md b/content/en/cosign/signing/other_types.md index ba19b640..c87ad7c1 100644 --- a/content/en/cosign/signing/other_types.md +++ b/content/en/cosign/signing/other_types.md @@ -17,49 +17,24 @@ Cosign can sign anything in a registry. Most of our examples show signing a sing ## SBOMs (Software Bill Of Materials) -SBOMs can also be stored in an OCI registry, using this [specification](https://github.com/sigstore/cosign/blob/main/specs/SBOM_SPEC.md). +There's a couple of different approaches SBOMs, depending on if you're working with container images or not. -Cosign can attach these using the `cosign attach sbom` command. In the following example, we'll be generating an SBOM for our sample container image by using the [syft](https://github.com/anchore/syft) tool created by Anchore community, then we'll be storing it in an OCI registry, once we store it, then we'll be signing the image tag that includes the SBOM itself, and verifying it. +If your SBOM is stored in a OCI registry, you can sign it and verify it like any other OCI object: ```shell -$ crane copy alpine:latest gcr.io/$(gcloud config get-value project)/alpine:latest +$ cosign sign --key cosign.key $SBOM_OCI_IMAGE -$ syft packages gcr.io/$(gcloud config get-value project)/alpine:latest -o spdx > latest.spdx - -$ cosign attach sbom --sbom latest.spdx gcr.io/$(gcloud config get-value project)/alpine:latest # get the digest from the output +$ cosign verify --key cosign.pub $SBOM_OCI_IMAGE ``` -Note that, attaching SBOMs this way does not sign them. If you want to sign the SBOM, you can use the following command: +Another option is to use `cosign attest` when signing your container image to include information about the SBOM: ```shell -$ cosign sign --key cosign.key gcr.io/$(gcloud config get-value project)/alpine:sha256-e1c082e3d3c45cccac829840a25941e679c25d438cc8412c2fa221cf1a824e6a.sbom - -$ cosign verify --key cosign.pub gcr.io/$(gcloud config get-value project)/alpine:sha256-e1c082e3d3c45cccac829840a25941e679c25d438cc8412c2fa221cf1a824e6a.sbom -``` - -Or you can include the SBOM in an [in-toto](https://in-toto.io) attestation, as illustrated in the following fragment: - -``` -{ - // Standard attestation fields: - "_type": "https://in-toto.io/Statement/v0.1", - "subject": [{ ... }], - - // Predicate: - "predicateType": "https://spdx.dev/Document", - "predicate": { - "SPDXID" : "SPDXRef-DOCUMENT", - "spdxVersion" : "SPDX-2.2", - ... - } -} +$ echo '{"sbom_path": "example.com/...", "sbom_hash": "sha256:0a1b2c..."}' > sbom.predicate.json +$ cosign attest --type custom --predicate sbom.predicate.json $IMAGE ``` -The following command signs and attaches the attestation to the image: - -```shell -$ cosign attest -predicate myattestations -key cosign.key gcr.io/$(gcloud config get-value project)/alpine:latest -``` +These approaches also work with files on disk, except you use `sign-blob` or `attest-blob` instead of the OCI versions `sign` or `attest`. ## Tekton Bundles @@ -77,23 +52,6 @@ Creating Tekton Bundle: Pushed Tekton Bundle to us.gcr.io/user-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155 $ cosign sign --key cosign.key us.gcr.io/user-vmtest2/pipeline:latest -Enter password for private key: -tlog entry created with index: 5086 -Pushing signature to: us.gcr.io/user-vmtest2/demo:sha256-124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155.sig -``` - -## WASM - -Web Assembly Modules can also be stored in an OCI registry, using this [specification](https://github.com/solo-io/wasm/tree/master/spec). - -Cosign can upload these using the `cosign upload wasm` command: - -```shell -$ cosign upload wasm -f hello.wasm us.gcr.io/user-vmtest2/wasm -$ cosign sign --key cosign.key us.gcr.io/user-vmtest2/wasm -Enter password for private key: -tlog entry created with index: 5198 -Pushing signature to: us.gcr.io/user-vmtest2/wasm:sha256-9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812.sig ``` ## OCI artifacts @@ -129,165 +87,12 @@ The following checks were performed on each of these signatures: {"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef"},"Type":"cosign container image signature"},"Optional":null} ``` -## Tag signing - -Cosign signatures protect the digests of objects stored in a registry. -The optional `annotations` support (via the `-a` flag to `cosign sign`) can be used to add extra -data to the payload that is signed and protected by the signature. -One use-case for this might be to sign a tag->digest mapping. - -If you would like to attest that a specific tag (or set of tags) should point at a digest, you can -run something like: - -```shell -$ TAG=sign-me -$ DGST=$(crane digest user/demo:$TAG) -$ cosign sign --key cosign.key -a tag=$TAG user/demo@$DGST -Enter password for private key: -Pushing signature to: user/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.sig -``` - -Then you can verify that the tag->digest mapping is also covered in the signature, using the `-a` flag to `cosign verify`. -This example verifies that the digest `$TAG` points to (`sha256:97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36`) -has been signed, **and also** that the `$TAG`: - -```shell -$ cosign verify --key cosign.pub -a tag=$TAG user/demo:$TAG | jq . -{ - "Critical": { - "Identity": { - "docker-reference": "" - }, - "Image": { - "Docker-manifest-digest": "97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36" - }, - "Type": "cosign container image signature" - }, - "Optional": { - "tag": "sign-me" - } -} -``` - -Timestamps could also be added here, to implement TUF-style freeze-attack prevention. - -## Base image and layer signing - -Again, Cosign can sign anything in a registry. -You could use `cosign` to sign an image that is intended to be used as a base image, -and include that provenance metadata in resulting derived images. -This could be used to enforce that an image was built from an authorized base image. - -Rough Idea: -* OCI manifests have an ordered list of `layer` `Descriptors`, which can contain annotations. - See [here](https://github.com/opencontainers/image-spec/blob/master/manifest.md) for the - specification. -* A base image is an ordered list of layers to which other layers are appended, as well as an - initial configuration object that is mutated. - * A derived image is free to completely delete/destroy/recreate the config from its base image, - so signing the config would provided limited value. -* We can sign the full set of ordered base layers, and attach that signature as an annotation to - the **last** layer in the resulting child image. - -This example manifest represents an image that has been built from a base image with two -layers. -One additional layer is added, forming the final image. - -```json -{ - "schemaVersion": 2, - "config": { - "mediaType": "application/vnd.oci.image.config.v1+json", - "size": 7023, - "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7" - }, - "layers": [ - { - "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip", - "size": 32654, - "digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0" - }, - { - "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip", - "size": 16724, - "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b", - "annotations": { - "dev.cosign.signature.baseimage": "Ejy6ipGJjUzMDoQFePWixqPBYF0iSnIvpMWps3mlcYNSEcRRZelL7GzimKXaMjxfhy5bshNGvDT5QoUJ0tqUAg==" - } - }, - { - "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip", - "size": 73109, - "digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736" - } - ], -} -``` - -Note that this could be applied recursively, for multiple intermediate base images. - -## Countersigning - -Cosign signatures (and their protected payloads) are stored as artifacts in a registry. -These signature objects can also be signed, resulting in a new, "counter-signature" artifact. -This "counter-signature" protects the signature (or set of signatures) **and** the referenced artifact, which allows -it to act as an attestation to the **signature(s) themselves**. - -Before we sign the signature artifact, we first give it a memorable name so we can find it later. - -```shell -$ cosign sign --key cosign.key -a sig=original user/demo -Enter password for private key: -Pushing signature to: user/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.sig -$ cosign verify --key cosign.pub user/demo | jq . -{ - "Critical": { - "Identity": { - "docker-reference": "" - }, - "Image": { - "Docker-manifest-digest": "97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36" - }, - "Type": "cosign container image signature" - }, - "Optional": { - "sig": "original" - } -} -``` - -Now give that signature a memorable name, then sign that: +## WASM -```shell -$ crane tag $(cosign triangulate user/demo) mysignature -2021/02/15 20:22:55 user/demo:mysignature: digest: sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e size: 556 -$ cosign sign --key cosign.key -a sig=counter user/demo:mysignature -Enter password for private key: -Pushing signature to: user/demo:sha256-71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e.sig -$ cosign verify --key cosign.pub user/demo:mysignature -{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e"},"Type":"cosign container image signature"},"Optional":{"sig":"counter"}} -``` +Web Assembly Modules can also be stored in an OCI registry, using this [specification](https://github.com/solo-io/wasm/tree/master/spec). -Finally, check the original signature: +See "OCI artifacts" above on how to upload items to an OCI registry. ```shell -$ crane manifest user/demo@sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e -{ - "schemaVersion": 2, - "config": { - "mediaType": "application/vnd.oci.image.config.v1+json", - "size": 233, - "digest": "sha256:3b25a088710d03f39be26629d22eb68cd277a01673b9cb461c4c24fbf8c81c89" - }, - "layers": [ - { - "mediaType": "application/vnd.oci.descriptor.v1+json", - "size": 217, - "digest": "sha256:0e79a356609f038089088ec46fd95f4649d04de989487220b1a0adbcc63fadae", - "annotations": { - "dev.sigstore.cosign/signature": "5uNZKEP9rm8zxAL0VVX7McMmyArzLqtxMTNPjPO2ns+5GJpBeXg+i9ILU+WjmGAKBCqiexTxzLC1/nkOzD4cDA==" - } - } - ] -} +$ cosign sign --key cosign.key us.gcr.io/user-vmtest2/wasm ``` diff --git a/content/en/cosign/signing/overview.md b/content/en/cosign/signing/overview.md index 503a1d7b..96cbcf46 100644 --- a/content/en/cosign/signing/overview.md +++ b/content/en/cosign/signing/overview.md @@ -77,14 +77,21 @@ $ cosign sign --identity-token=$( On Google Cloud Build, the standard identity tokens endpoint is also available thorugh its metadata server as described [here](https://docs.cloud.google.com/build/docs/securing-builds/authorize-service-to-service-access). ## Custom infrastructure -If you're running your own Sigstore services flags are available to set your own endpoint's, e.g +If you're running your own Sigstore services, first create a signing config to point to your servers: +```shell +$ cosign signing-config create \ + --fulcio="url=https://fulcio.example.com,api-version=1,start-time=2024-01-01T00:00:00Z,operator=example.com" \ + --rekor="url=https://rekor.example.com,api-version=2,start-time=2024-01-01T00:00:00Z,operator=example.com" \ + --rekor-config="ANY" \ + --output-file custom.signingconfig.json ``` - cosign sign --oidc-issuer "https://oauth2.example.com/auth" \ - --fulcio-url "https://fulcio.example.com" \ - --rekor-url "https://rekor.example.com" \ - ghcr.io/jdoe/somerepo/testcosign +Then sign an image with your custom signing config: + +```shell +$ cosign sign --signing-config custom.signingconfig.json \ + ghcr.io/jdoe/somerepo/testcosign ``` ### Custom roots of trust diff --git a/content/en/cosign/signing/signing_with_blobs.md b/content/en/cosign/signing/signing_with_blobs.md index 483bc34a..cff34b8d 100644 --- a/content/en/cosign/signing/signing_with_blobs.md +++ b/content/en/cosign/signing/signing_with_blobs.md @@ -12,52 +12,17 @@ You can use Cosign for signing and verifying standard files and blobs (or binary Cosign supports identity-based signing, associating an ephemeral signing key with an identity from an OpenID Connect provider. We refer to this process as "keyless signing". You use `cosign sign-blob` to sign standard files as well as blobs. You can store signature and certificate information either as separate file, or in a bundled text file, but using a bundle is the recommended way of signing a blob, as users can specify just the bundle name instead of separate files for the signature and certificate. Use the `cosign` command to sign: ```shell -$ cosign sign-blob --bundle artifact.sigstore.json -``` -The bundle contains verification metadata, including an artifact's signature, certificate and proof of transparency log inclusion. - -When using `cosign sign-blob` in keyless mode, you need to store the bundle for verification. If you don't want to use the bundle, you can direct the output of the certificate by using the `--output-certificate` and `--output-signature` flags. Note that this will be removed in future versions of Cosign, as the -bundle format is standardized across Sigstore clients. The result from using the output flags: - -```shell -$ cosign sign-blob README.md --new-bundle-format=false --output-certificate cert.pem --output-signature sig -Using payload from: README.md -Generating ephemeral keys... -Retrieving signed certificate... -Your browser will now be opened to: -https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=0D8yG7r5IUq77b4egHdmwl0Qibx4AFeLTZDfJVwHLHU&code_challenge_method=S256&nonce=22WQwzdXicldeusZNTXuwY0WBcG&redirect_uri=http%3A%2F%2Flocalhost%3A56461%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=22WQwzRfkMPUI6NIRHhpdcWFHjt -Successfully verified SCT... -using ephemeral certificate: ------BEGIN CERTIFICATE----- -MIICojCCAiegAwIBAgITXUsve2wjuSq6KkM+u+SpeaAMejAKBggqhkjOPQQDAzAq -MRUwEwYDVQQKEwxzaWdzdG9yZS5kZXYxETAPBgNVBAMTCHNpZ3N0b3JlMB4XDTIx -MTIxOTIxNTgyOFoXDTIxMTIxOTIyMTgyN1owADBZMBMGByqGSM49AgEGCCqGSM49 -AwEHA0IABN58WDnzn3s9DZ8SmT5KWSLlnOYl3nAHfP1EfV+lAno39GWWvcVW2htp -Vapzctx5L2Y7JcX8kc8i0rbG36zaBwajggFUMIIBUDAOBgNVHQ8BAf8EBAMCB4Aw -EwYDVR0lBAwwCgYIKwYBBQUHAwMwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUG45K -i7pgxuixE7EpWiwHzrrFPR0wHwYDVR0jBBgwFoAUyMUdAEGaJCkyUSTrDa5K7UoG -0+wwgY0GCCsGAQUFBwEBBIGAMH4wfAYIKwYBBQUHMAKGcGh0dHA6Ly9wcml2YXRl -Y2EtY29udGVudC02MDNmZTdlNy0wMDAwLTIyMjctYmY3NS1mNGY1ZTgwZDI5NTQu -c3RvcmFnZS5nb29nbGVhcGlzLmNvbS9jYTM2YTFlOTYyNDJiOWZjYjE0Ni9jYS5j -cnQwIAYDVR0RAQH/BBYwFIESbG9yZW5jLmRAZ21haWwuY29tMCkGCisGAQQBg78w -AQEEG2h0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbTAKBggqhkjOPQQDAwNpADBm -AjEAhcn+ORgRzA/m4VZ7tUzEs1aTAl87PlVisQIOFW3cBj/5om5vO2hbxptZvORb -adLkAjEAqGj3Dv/DQ0BSnb1mFPrZGp6So4XE9OsV8EUTBXc0mpd1fsmotdhc4KQO -PHpisPhj ------END CERTIFICATE----- - -tlog entry created with index: 965333 -Signature wrote in the file sig -Certificate wrote in the file cert.pem +$ cosign sign-blob --bundle bundle.sigstore.json ``` +The bundle contains verification metadata, including an artifact's signature, certificate and proof of transparency log inclusion. You need to store the bundle for verification. ## Signing with a key While keyless signing is recommended, you may specify your own keys for signing. You will need the password for the private key to sign: ```shell -$ cosign sign-blob --key cosign.key --bundle artifact.sigstore.json README.md +$ cosign sign-blob --key cosign.key --bundle bundle.sigstore.json README.md Using payload from: README.md Enter password for private key: MEQCIAU4wPBpl/U5Vtdx/eJFgR0nICiiNCgyWPWarupH0onwAiAv5ycIKgztxHNVG7bzUjqHuvK2gsc4MWxwDgtDh0JINw== @@ -65,42 +30,10 @@ MEQCIAU4wPBpl/U5Vtdx/eJFgR0nICiiNCgyWPWarupH0onwAiAv5ycIKgztxHNVG7bzUjqHuvK2gsc4 This supports all the same flags and features as `cosign sign`, including KMS support, hardware tokens, and keyless signatures. See [Signing with Self-Managed Keys]({{< relref "cosign/key_management/signing_with_self-managed_keys">}}) for more information. -## Blobs in OCI Registries - -You can upload blobs to an OCI registry (similar to [ORAS](https://github.com/oras-project/oras)) where they can then be signed like any other image. - -You can publish an artifact with `cosign upload blob`: - -```shell -$ echo "my first artifact" > artifact -$ cosign upload blob -f artifact gcr.io/user/demo/artifact -Uploading file from [artifact] to [gcr.io/user/demo/artifact:latest] with media type [text/plain; charset=utf-8] -File is available directly at [us.gcr.io/v2/user/demo/readme/blobs/sha256:b57400c0ad852a7c2f6f7da4a1f94547692c61f3e921a49ba3a41805ae8e1e99] -us.gcr.io/user/demo/readme@sha256:4aa3054270f7a70b4528f2064ee90961788e1e1518703592ae4463de3b889dec -``` - -Your users can download it from the "direct" URL with standard tools like curl or wget: - -```shell -$ curl -L gcr.io/v2/user/demo/artifact/blobs/sha256:97f16c28f6478f3c02d7fff4c7f3c2a30041b72eb6852ca85b919fd85534ed4b > artifact -``` - -The digest is included in the URL, so users can check that as well: - -```shell -$ curl -L gcr.io/v2/user/demo/artifact/blobs/sha256:97f16c28f6478f3c02d7fff4c7f3c2a30041b72eb6852ca85b919fd85534ed4b | shasum -a 256 -97f16c28f6478f3c02d7fff4c7f3c2a30041b72eb6852ca85b919fd85534ed4b - -``` - -You can sign it with the normal `cosign sign` command and flags: - -```shell -$ cosign sign gcr.io/user/demo/artifact -``` ## Non-Interactive Signing with the Yes Flag In situations where automated signing is required, such as within CI/CD pipelines, the `--yes` flag becomes essential. This flag, when used with signing commands, bypasses any confirmation prompts, enabling a smooth, uninterrupted signing process. This is particularly crucial in automated environments where manual input isn't feasible. The `--yes` flag ensures that your signing operations can proceed without manual intervention, maintaining the efficiency and speed of your automated workflows. ``` -cosign sign-blob --yes --key cosign.key --bundle artifact.sigstore.json myregistry/myimage:latest +$ cosign sign-blob --yes --key cosign.key --bundle bundle.sigstore.json myregistry/myimage:latest ``` diff --git a/content/en/cosign/signing/signing_with_containers.md b/content/en/cosign/signing/signing_with_containers.md index 505a1479..09314a62 100644 --- a/content/en/cosign/signing/signing_with_containers.md +++ b/content/en/cosign/signing/signing_with_containers.md @@ -13,14 +13,19 @@ The format for keyless signing of a container is as follows. $ cosign sign $IMAGE ``` -> NOTE: You will need access to a container registry for Cosign to work with. [ttl.sh](https://ttl.sh/) offers free, short-lived (ie: hours), anonymous container image hosting if you just want to try these commands out. +> NOTE: You will need access to a container registry for Cosign to work with. If you're not sure what container registry to use, you can set up a local one for testing. -To create a test image to sign using [ttl.sh](https://ttl.sh), run the following commands: +[google/go-containerregistry](https://github.com/google/go-containerregistry) allows you to run a container registry locally, and [ko-build/ko] lets you build an image: +```shell +google/go-containerregistry$ go run cmd/registry/main.go +serving on port 1338 ``` -$ IMAGE_NAME=$(uuidgen | tr '[:upper:]' '[:lower:]') -$ IMAGE=ttl.sh/$IMAGE_NAME:1h -$ cosign copy alpine $IMAGE + +```shell +sigstore/cosign$ ko build cmd/conformance/main.go +Published localhost:1338/demo/main.go-38af7bca496e2316e5b02c5d5bafd5f3@sha256:a5a6744c9d069ac7081ceccc2291995a999f02b027995cd5e8508f35e40e7dd1 +$ export IMAGE=localhost:1338/demo/main.go-38af7bca496e2316e5b02c5d5bafd5f3@sha256:a5a6744c9d069ac7081ceccc2291995a999f02b027995cd5e8508f35e40e7dd1 ``` ## General signing format @@ -28,7 +33,7 @@ $ cosign copy alpine $IMAGE The general signing format with the `cosign sign` command is as follows. ```shell -$ cosign sign [--key |] [--payload ] [-a key=value] [--upload=true|false] [-f] [-r] +$ cosign sign [--key |] [-r] ``` ## Sign with a local key pair @@ -43,7 +48,7 @@ If you need to generate local keys, you can do so by running `cosign generate-ke ## Sign a container multiple times -Multiple signatures can be "attached" to a single container image. In this example, the container is signed and then signed again: +Multiple signatures can refer to a single container image. In this example, the container is signed and then signed again: ```shell $ cosign sign $IMAGE @@ -51,31 +56,16 @@ $ cosign sign $IMAGE $ cosign sign $IMAGE ``` -## Add annotations with a signature +## Attesting an image -The `-a` flag can be used to add annotations to the generated, signed payload. - -This flag can be repeated: +If you have metadata you want to include along with the signature, use `cosign attest`: ```shell -$ cosign sign -a foo=bar $IMAGE -``` - -These values are included in the signed payload under the `Optional` section. - -```json -"Optional":{"baz":"bat","foo":"bar"} +$ echo '{"foo": "bar"}' > attest.predicate.json +$ cosign attest --type custom --predicate attest.predicate.json $IMAGE ``` -They can be verified with the `-a` flag as part of the `cosign verify` command. - -## Sign and attach a certificate and certificate chain - -You can sign a container and attach an existing certificate and certificate chain to an image. Note that you cannot currently generate a certificate chain but can use an existing chain. - -```shell -$ cosign sign --certificate cosign.crt --certificate-chain chain.crt $IMAGE -``` +They can be verified with the `--policy` flag as part of the `cosign verify-attestation` command. ## Sign with a key pair stored elsewhere @@ -124,222 +114,28 @@ $ cosign sign --key hashivault://[KEY] $IMAGE $ cosign sign --key k8s://[NAMESPACE]/[KEY] $IMAGE ``` -## Sign and upload a generated payload (in another format, from another tool) +## Skip uploading signature to container registry -The payload must be specified as a path to a file. +If for some reason you do not want to store the signature in the container registry, you can save the signed material as a Sigstore bundle: ```shell -$ cosign sign --payload README.md $IMAGE -Using payload from: README.md +$ cosign sign --bundle=bundle.sigstore.json --upload=false $IMAGE ``` -You can also sign with another tool. -Cosign uses standard PKIX cryptographic formats, here's a full example with `openssl`: - -```shell -# Generate a keypair -$ openssl ecparam -name prime256v1 -genkey -noout -out openssl.key -$ openssl ec -in openssl.key -pubout -out openssl.pub -# Generate the payload to be signed -$ cosign generate $IMAGE > payload.json -# Sign it and convert to base64 -$ openssl dgst -sha256 -sign openssl.key -out payload.sig payload.json -$ cat payload.sig | base64 > payloadbase64.sig -# Upload the signature -$ cosign attach signature --payload payload.json --signature payloadbase64.sig $IMAGE - -# Verify! Need to pass `--insecure-ignore-tlog` because attaching a signature -# doesn't upload it to the transparency log. -$ cosign verify --key openssl.pub --insecure-ignore-tlog $IMAGE - -Verification for us.gcr.io/user/demo -- -The following checks were performed on each of these signatures: - - The cosign claims were validated - - The signatures were verified against the specified public key - - Any certificates were verified against the Fulcio roots. -{"critical":{"identity":{"docker-reference":"us.gcr.io/user/demo"},"image":{"docker-manifest-digest":"sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155"},"type":"cosign container image signature"},"optional":null} -``` - -## Sign but skip upload (to store somewhere else) - -The upload is skipped by using the `--upload=false` flag (default true). To capture the output use the `--output-signature FILE` and/or `--output-certificate FILE` flags. - -```shell -$ cosign sign --upload=false --output-signature demo.sig --output-certificate demo.crt $IMAGE -``` - -## Generate the Signature Payload with Cosign (to sign with another tool) - -You can also use other tools for signing - not just `cosign`. This section will provide examples of how to sign with tools other than `cosign`. - -### GCP KMS with `gcloud` +## Upload signature to a container registry later -To sign with `gcloud kms`, first use `cosign generate` to generate the payload and dump it into a JSON file: +If you want to upload that bundle to a container registry later, we recommend you do so with [oras](https://oras.land/): ```shell -$ cosign generate us-central1-docker.pkg.dev/user/test/taskrun > payload.json -``` - -Sign the payload with `gcloud kms`: - -```shell -$ gcloud kms asymmetric-sign \ - --digest-algorithm=sha256 \ - --input-file=payload.json \ - --signature-file=gcpkms.sig \ - --key=foo \ - --keyring=foo \ - --version=1 \ - --location=us-central -``` - -Base64 encode the signature into a temporary variable and use it to upload with `cosign`: - -```shell -$ BASE64_SIGNATURE=$(cat gcpkms.sig | base64) -$ cosign attach signature --payload payload.json --signature $BASE64_SIGNATURE us-central1-docker.pkg.dev/user/test/taskrun -``` - -Now (on another machine) use `cosign` to download signature bundle and dump into a JSON file: - -```shell -$ cosign download signature us-central1-docker.pkg.dev/user/test/taskrun > signatures.json -``` - -Extract a payload and signature value and dump into their own respective files: - -```shell -$ cat signatures.json | tail -1 | jq -r .Payload | base64 -d > payload -$ cat signatures.json | tail -1 | jq -r .Base64Signature | base64 -d > signature -``` - -Download (on the same machine as the previous step) the public key: - -```shell -$ gcloud kms keys versions get-public-key 1 --key=foo --keyring=foo --location=us-central1 > pubkey.pem -``` - -Finally, verify the signature with `openssl`: - -```shell -$ openssl dgst -sha256 -verify pubkey.pem -signature gcpkms.sig payload -``` - -### AWS KMS with `aws` - -To use a AWS KMS CMK (Custom Master Key) for signing and verification, first create the CMK (just need to do this once) using the `aws` CLI (Version 2): - -```shell -$ export AWS_CMK_ID=$(aws kms create-key --customer-master-key-spec RSA_4096 \ - --key-usage SIGN_VERIFY \ - --description "Cosign Signature Key Pair" \ - --query KeyMetadata.KeyId --output text) -``` - -Use `cosign` to generate the payload: - -```shell -$ cosign generate docker.io/davivcgarcia/hello-world:latest > payload.json -``` - -Sign the payload with the AWS KMS CMK we created above: - -```shell -$ aws kms sign --key-id $AWS_CMK_ID \ - --message file://payload.json \ - --message-type RAW \ - --signing-algorithm RSASSA_PKCS1_V1_5_SHA_256 \ - --output text \ - --query Signature > payload.sig -``` - -Upload the signature with `cosign`: - -```shell -$ cosign attach signature docker.io/davivcgarcia/hello-world:latest --signature $(< payload.sig) --payload payload.json -``` - -Now (on another machine) use cosign to download signature bundle and dump into a JSON file: - -```shell -$ cosign download signature docker.io/davivcgarcia/hello-world:latest > signatures.json -``` - -Extract the payload and signature value and dump into their own respective files: - -```shell -$ cat signatures.json | tail -1 | jq -r .Base64Signature | base64 -d > remote_payload.sig -$ cat signatures.json | tail -1 | jq -r .Payload | base64 -d > remote_payload.json -``` - -Verify with AWS KMS using the CMK key we created in the first step: - -```shell -$ aws kms verify --key-id $AWS_CMK_ID \ - --message file://remote_payload.json \ - --message-type RAW \ - --signing-algorithm RSASSA_PKCS1_V1_5_SHA_256 \ - --signature fileb://remote_payload.sig \ - --output text \ - --query SignatureValid -``` - -## Upload a generated signature - -The signature is passed via the `--signature` flag. It can be a file: - -```shell -$ cosign attach signature --signature file.sig $IMAGE -``` - -Or, `-` for `stdin` for chaining from other commands: - -```shell -$ cosign generate $IMAGE | openssl... | cosign attach signature --signature - $IMAGE -Pushing signature to: user/demo:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def.sig +$ oras attach --artifact-type=application/vnd.dev.sigstore.bundle.v0.3+json $IMAGE bundle.sigstore.json ``` ## Signature location and management -Signatures are uploaded to an OCI artifact stored with a predictable name. -This name can be located with the `cosign triangulate` command: - -```shell -$ cosign triangulate $IMAGE -index.docker.io/user/demo:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8.sig -``` - -They can be reviewed with `crane`: +Signatures use the OCI 1.1 referrer specification. You can use `cosign tree` to find attached signatures: ```shell -$ crane manifest $(cosign triangulate $IMAGE) | jq . -{ - "schemaVersion": 2, - "mediaType": "application/vnd.docker.distribution.manifest.v2+json", - "config": { - "mediaType": "application/vnd.docker.container.image.v1+json", - "size": 342, - "digest": "sha256:f5de0db6e714055d48b4bb3a374e9630c4923fa704d9311da6a2740cf625aaba" - }, - "layers": [ - { - "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json", - "size": 210, - "digest": "sha256:1119abab63e605dcc281019bad0424744178b6f61ba57378701fe7391994c999", - "annotations": { - "dev.cosignproject.cosign/signature": "MEUCIG0ZmgqE3qTrHWp+HF9CrxsNH57Cck3cQI+zNNrUwSHfAiEAm+2eY/Z6ixQwjLbTraDN5ZB/P1Z5k/KwIoblry65r+s=" - } - }, - { - "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json", - "size": 219, - "digest": "sha256:583246418c2afd5bfe29694793d07da37ffd552aadf8879b1d98047178b80398", - "annotations": { - "dev.cosignproject.cosign/signature": "MEUCIF/+szLKKA2q2+c86AXeWR7UeD5yYpW7p0waHordxNjhAiEAm5e+Hm7Jhv9JpSwHpTc6aGLSkL6/Acm/z+b8mhfGXqY=" - } - } - ] -} +$ cosign tree $IMAGE ``` Some registries support deletion too (DockerHub does not): From 95c9755b542087e123026a25e286b9bdf873d883 Mon Sep 17 00:00:00 2001 From: Zach Steindler Date: Fri, 6 Mar 2026 14:36:21 -0500 Subject: [PATCH 2/4] Remove additional reference to gitsign Signed-off-by: Zach Steindler --- content/en/about/overview.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/en/about/overview.md b/content/en/about/overview.md index 68b0e148..4c0ba2fd 100644 --- a/content/en/about/overview.md +++ b/content/en/about/overview.md @@ -64,7 +64,6 @@ To use Sigstore, you must first install the client. Review the [Installation]({{ - To get a quick view of how to use the program see [Quick Start]({{< relref "quickstart/quickstart-cosign">}}) - To learn how to work with blobs, see [sign a blob]({{< relref "cosign/signing/signing_with_blobs">}}) - To learn how to work with containers, see [sign a container]({{< relref "cosign/signing/signing_with_containers">}}) -- To use Gitsign, see [Sign Git commits with Gitsign]({{< relref "cosign/signing/gitsign">}}) - To learn about verification, see [the importance of verification]({{< relref "about/the-importance-of-verification">}}) and [verify entries with Cosign]({{< relref "cosign/verifying/verify">}}) - To learn about incorporating Sigstore into your CI System, see [our CI Quickstart]({{< relref "quickstart/quickstart-ci">}}) From 7c4d7a9a6f08d0d68497d51f34f962d325203a51 Mon Sep 17 00:00:00 2001 From: Zach Steindler Date: Mon, 9 Mar 2026 16:10:16 -0400 Subject: [PATCH 3/4] Add ko link; update Cosign quickstart to be consistent Signed-off-by: Zach Steindler --- .../cosign/signing/signing_with_containers.md | 2 +- content/en/quickstart/quickstart-cosign.md | 17 ++++++++++------- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/content/en/cosign/signing/signing_with_containers.md b/content/en/cosign/signing/signing_with_containers.md index 09314a62..4fb747c0 100644 --- a/content/en/cosign/signing/signing_with_containers.md +++ b/content/en/cosign/signing/signing_with_containers.md @@ -15,7 +15,7 @@ $ cosign sign $IMAGE > NOTE: You will need access to a container registry for Cosign to work with. If you're not sure what container registry to use, you can set up a local one for testing. -[google/go-containerregistry](https://github.com/google/go-containerregistry) allows you to run a container registry locally, and [ko-build/ko] lets you build an image: +[google/go-containerregistry](https://github.com/google/go-containerregistry) allows you to run a container registry locally, and [ko-build/ko](https://github.com/ko-build/ko) lets you build an image: ```shell google/go-containerregistry$ go run cmd/registry/main.go diff --git a/content/en/quickstart/quickstart-cosign.md b/content/en/quickstart/quickstart-cosign.md index 78044c5d..b9806c81 100644 --- a/content/en/quickstart/quickstart-cosign.md +++ b/content/en/quickstart/quickstart-cosign.md @@ -64,16 +64,19 @@ artifact and its certificate. ## Example: Working with containers -> NOTE: In this example, we will create a container using [ttl.sh](https://ttl.sh/). It offers free, short-lived (as in minutes or hours), anonymous container image hosting so you can try out signing and verifying commands in a sample workflow +> NOTE: You will need access to a container registry for Cosign to work with. If you're not sure what container registry to use, you can set up a local one for testing. -To use `ttl.sh` and [crane](https://github.com/google/go-containerregistry/tree/main/cmd/crane) to prepare the image to sign, run the following: +[google/go-containerregistry](https://github.com/google/go-containerregistry) allows you to run a container registry locally, and [ko-build/ko](https://github.com/ko-build/ko) lets you build an image: +```shell +google/go-containerregistry$ go run cmd/registry/main.go +serving on port 1338 ``` -$ SRC_IMAGE=busybox -$ SRC_DIGEST=$(crane digest busybox) -$ IMAGE_URI=ttl.sh/$(uuidgen | head -c 8 | tr 'A-Z' 'a-z') -$ crane cp $SRC_IMAGE@$SRC_DIGEST $IMAGE_URI:1h -$ IMAGE_URI_DIGEST=$IMAGE_URI@$SRC_DIGEST + +```shell +sigstore/cosign$ ko build cmd/conformance/main.go +Published localhost:1338/demo/main.go-38af7bca496e2316e5b02c5d5bafd5f3@sha256:a5a6744c9d069ac7081ceccc2291995a999f02b027995cd5e8508f35e40e7dd1 +$ export IMAGE_URI_DIGEST=localhost:1338/demo/main.go-38af7bca496e2316e5b02c5d5bafd5f3@sha256:a5a6744c9d069ac7081ceccc2291995a999f02b027995cd5e8508f35e40e7dd1 ``` ### Keyless signing of a container From 6194ae32087b46a37699bf7e6a6df1978accaaa9 Mon Sep 17 00:00:00 2001 From: Zach Steindler Date: Wed, 11 Mar 2026 08:33:39 -0400 Subject: [PATCH 4/4] Add TSA to signing-config example Signed-off-by: Zach Steindler --- content/en/cosign/signing/overview.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/cosign/signing/overview.md b/content/en/cosign/signing/overview.md index 96cbcf46..1eecf3a1 100644 --- a/content/en/cosign/signing/overview.md +++ b/content/en/cosign/signing/overview.md @@ -84,6 +84,8 @@ $ cosign signing-config create \ --fulcio="url=https://fulcio.example.com,api-version=1,start-time=2024-01-01T00:00:00Z,operator=example.com" \ --rekor="url=https://rekor.example.com,api-version=2,start-time=2024-01-01T00:00:00Z,operator=example.com" \ --rekor-config="ANY" \ + --tsa="url=https://tsa.example.com,api-version=1,start-time=2024-01-01T00:00:00Z,operator=example.com" \ + --tsa-config="ANY" \ --output-file custom.signingconfig.json ```