コンテナとバイナリ向けのコード署名と透明性
<p align="center">
<img style="max-width: 100%;width: 300px;" src="https://raw.githubusercontent.com/sigstore/community/main/artwork/cosign/horizontal/color/sigstore_cosign-horizontal-color.svg" alt="Cosign logo"/>
</p>
# cosign
[Sigstore](https://sigstore.dev/) を使用して OCI コンテナ（およびその他のアーティファクト）に署名する！
[](https://goreportcard.com/report/github.com/sigstore/cosign)
[](https://github.com/sigstore/cosign/actions/workflows/e2e-tests.yml)
[](https://bestpractices.coreinfrastructure.org/projects/5715)
[](https://securityscorecards.dev/viewer/?uri=github.com/sigstore/cosign)
Cosign は署名を **見えないインフラストラクチャ** にすることを目指しています。
Cosign は以下をサポートしています：
* Sigstore の公共財である Fulcio 認証局と Rekor 透明性ログを使用した「キーレス署名」（デフォルト）
* ハードウェアおよび KMS 署名
* cosign が生成した暗号化された秘密鍵/公開鍵ペアによる署名
* OCI レジストリにおけるコンテナの署名、検証、保存
* 独自 PKI の持ち込み
## 情報
`Cosign` は [`sigstore`](https://sigstore.dev) プロジェクトの一部として開発されています。
また、[slack チャンネル](https://sigstore.slack.com)も利用しています！
招待リンクは[こちら](https://join.slack.com/t/sigstore/shared_invite/zt-47srvpyn6-j8Ek5hGBwKN32IjLw8BvYA)をクリックしてください。
## インストール
Homebrew、Arch、Nix、GitHub Action、Kubernetes でのインストールについては、[インストールドキュメント](https://docs.sigstore.dev/cosign/system_config/installation/)を参照してください。
Linux、macOS、Windows のバイナリについては、[GitHub リリースアセット](https://github.com/sigstore/cosign/releases/latest)を参照してください。
:rotating_light: 当社の GCS バケットから cosign のリリースをダウンロードしている場合は、2023年7月31日の[非推奨のお知らせ](https://blog.sigstore.dev/cosign-releases-bucket-deprecation/)に関する詳細をご確認ください :rotating_light:
## 開発者向けインストール
Go 1.22 以降をお持ちであれば、開発環境をセットアップできます：
```shell
$ git clone https://github.com/sigstore/cosign
$ cd cosign
$ go install ./cmd/cosign
$ $(go env GOPATH)/bin/cosign
```
## コントリビューション
`cosign` へのコントリビューションにご興味をお持ちの場合は、[コントリビューションに関するドキュメント](https://github.com/sigstore/cosign/blob/main/CONTRIBUTING.md)をお読みください。
今後の Cosign の開発は、[sigstore-go](https://github.com/sigstore/sigstore-go) をベースとした次のメジャーリリースに焦点を当てます。メンテナーは sigstore-go 内での機能開発に注力します。sigstore-go へのコントリビューション、特に bring-your-own keys と署名に関するものは歓迎します。初心者向けの issue については、[issue tracker](https://github.com/sigstore/sigstore-go/issues)をご覧ください。
Cosign 2.x は安定版リリースであり、引き続き定期的な機能アップデートとバグ修正を受けます。範囲と規模が小さい PR は、迅速にレビューされる可能性が最も高いです。
API を大幅に変更または破壊する PR は受け入れられません。規模は大きいものの破壊的変更を導入しない PR は受け入れられる可能性がありますが、sigstore-go の PR よりも優先度が低いと見なされます。
## Dockerfile
以下は、ghcr.io/sigstore/cosign/cosign イメージを通じて Dockerfile 内で cosign をインストールして使用する方法です:
```shell
FROM ghcr.io/sigstore/cosign/cosign:v2.4.1 as cosign-bin
# Source: https://github.com/chainguard-images/images/tree/main/images/static
FROM cgr.dev/chainguard/static:latest
COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
ENTRYPOINT [ "cosign" ]
```
## クイックスタート
ここでは以下の方法を説明します:
* デフォルトのIDベースの「キーレス署名」方式でコンテナイメージに署名する（詳細は[ドキュメントを参照](https://docs.sigstore.dev/cosign/signing/overview/)）
* コンテナイメージを検証する
* [Sigstore Cosign Quickstart](https://docs.sigstore.dev/quickstart/quickstart-cosign/)で、より広範なキーレスBlob署名/検証のフローを探る
### コンテナに署名し、署名をレジストリに保存する
イメージには常にタグ（`:latest`）ではなくダイジェスト（`@sha256:...`）に基づいて署名すべきであることに注意してください。そうしないと、意図しないものに署名してしまう可能性があります！
```shell
cosign sign $IMAGE
Generating ephemeral keys...
Retrieving signed certificate...
Note that there may be personally identifiable information associated with this signed artifact.
This may include the email address associated with the account with which you authenticate.
This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.
Are you sure you would like to continue? [y/N] y
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY&code_challenge_method=S256&nonce=2KvOWeTFxYfxyzHtssvlIXmY6Jk&redirect_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2KvOWfbQJ1caqScgjwibzK2qJmb
Successfully verified SCT...
tlog entry created with index: 12086900
Pushing signature to: $IMAGE
```
CosignはOIDCによる認証を求め、そこでメールアドレスを使用してサインインします。
内部的には、cosignはFulcio認証局からコード署名証明書を要求します。
証明書のサブジェクトは、ログインに使用したメールアドレスと一致します。
その後、cosignは署名と証明書をRekor透明性ログに保存し、署名を署名対象のイメージとともにOCIレジストリにアップロードします。
### コンテナの検証
イメージを検証するには、`--certificate-identity` および `--certificate-oidc-issuer` フラグを介して、期待される証明書サブジェクトと証明書発行者を渡す必要があります:
```
cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-issuer=$OIDC_ISSUER
```
証明書のアイデンティティと発行者のフラグには、正規表現を渡すこともできます。`--certificate-identity-regexp` と `--certificate-oidc-issuer-regexp` です。
### 公開鍵に対してコンテナを検証する
このコマンドは、イメージに対して *少なくとも1つ* の `cosign` 形式の署名が公開鍵と一致して見つかった場合に `0` を返します。
他の署名形式に関する情報と注意事項については、以下の詳細な使用法を参照してください。
有効なペイロードはすべて json 形式で stdout に出力されます。
これらの署名済みペイロードにはコンテナイメージのダイジェストが含まれており、これによってこれらの「デタッチされた」署名が正しいイメージを対象としていることを確信できることに注意してください。
```shell
$ cosign verify --key cosign.pub $IMAGE_URI:1h
The following checks were performed on these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}
```
### エアギャップ環境でのコンテナの検証
**注:** このセクションは古くなっています。
**注:** ほとんどの検証ワークフローでは、TUF リポジトリからサービスキーを定期的に要求する必要があります。
public-good インスタンスを使用した署名のエアギャップ検証では、本番環境の
TUF リポジトリから
[trusted root](https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json) ファイルを取得する必要があります。このファイルの内容は予告なく変更されます。TUF を使用しない場合、このファイルのエアギャップコピーを最新の状態に保つための独自の仕組みを構築する必要があります。
Cosign は、通常イメージマニフェストのアノテーションとして配布される [bundle](https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md#properties) を検証することで、完全にオフラインでの検証を行うことができます。
このアノテーションが存在する限り、オフライン検証を実行できます。
この bundle アノテーションはキーレス署名では常にデフォルトで含まれるため、デフォルトの `cosign sign` 機能にはオフライン検証に必要なすべての素材が含まれます。
エアギャップ環境でイメージを検証するには、イメージと署名がファイルシステム上でローカルに利用可能である必要があります。
イメージは `cosign save` を使用してローカルに保存できます（注: この手順はネットワーク接続のある状態で行う必要があります）:
```
cosign initialize # This will pull in the latest TUF root
cosign save $IMAGE_NAME --dir ./path/to/dir
```
エアギャップ環境で、このローカルイメージを検証できるようになりました:
```shell
cosign verify \
--certificate-identity $CERT_IDENTITY \
--certificate-oidc-issuer $CERT_OIDC_ISSUER \
--offline=true \
--new-bundle-format=false \ # for artifacts signed without the new protobuf bundle format
--trusted-root ~/.sigstore/root/tuf-repo-cdn.sigstore.dev/targets/trusted_root.json \ # default location of trusted root
--local-image ./path/to/dir
```
`$CERT_IDENTITY` と `$CERT_OIDC_ISSUER` に期待値を渡して、このイメージを正しく検証する必要があります。
キーペアで署名した場合、公開鍵の素材がローカルに存在することを前提として、同じコマンドが機能します:
```
cosign verify --key cosign.pub --offline --local-image ./path/to/dir
```
### ID ベースの blob 署名と検証
キーレス blob 署名（`--key` なしの `cosign sign-blob`）を使用し、期待される署名者 ID に対して検証します：
```shell
$ cosign sign-blob artifact --bundle artifact.sigstore.json --yes
$ cosign verify-blob artifact \
--bundle artifact.sigstore.json \
--certificate-identity "https://github.com/ORG/REPO/.github/workflows/release.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
```
### トラブルシューティング
Cosign で問題が発生した場合は、まず最新リリースを使用していることを確認してください。Cosign プロジェクトは、最新リリースおよび v2 シリーズの直前のリリースを積極的にサポートしています。
#### よくある問題と対処法
1. 検証が `failed to verify timestamps: threshold not met for verified log entry integrated timestamps: 0 < 1` で失敗する: RFC3161 タイムスタンプサポートを必要とする署名を検証している可能性があります
* 最新の Cosign にアップグレードする、または
* Cosign 2.6.x では `--use-signed-timestamps` を使用する
1. 検証が `no signatures found` で失敗する: Rekor v2 透明性ログのサポートを必要とするイメージ署名を検証している可能性があります
* 最新の Cosign にアップグレードする
1. 署名が HTTP エラーで失敗する: Cosign での署名は複数の Sigstore サービスに依存しています。これらのサービスのいずれかが失敗した場合、再試行が有効な回避策となることがあります -- 特定の失敗について issue を報告していただけると助かります
#### 私の問題は別のことです
[issue](https://github.com/sigstore/cosign/issues/new/choose) を作成するか、[slack channel](#info) で質問してください。
## その他のアーティファクトの扱い
OCI レジストリは、コンテナイメージだけでなく、さまざまなものを保存するのに便利です！
`Cosign` には、バイナリ、スクリプト、設定ファイルなどの汎用アーティファクトを OCI プロトコルを使用して公開するためのユーティリティも含まれています。
このセクションでは、これらを活用して、Sigstore の他の部分とうまく統合された、使いやすく後方互換性のあるアーティファクト配布システムを構築する方法を説明します。
詳細については、[the documentation](https://docs.sigstore.dev/cosign/signing/other_types/) を参照してください。
### Blobs
`cosign upload blob` を使用してアーティファクトを公開できます:
```shell
$ echo "my first artifact" > artifact
$ BLOB_SUM=$(shasum -a 256 artifact | cut -d' ' -f 1) && echo "$BLOB_SUM"
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626
$ BLOB_NAME=my-artifact-$(uuidgen | head -c 8 | tr 'A-Z' 'a-z')
$ BLOB_URI=ttl.sh/$BLOB_NAME:1h
$ BLOB_URI_DIGEST=$(cosign upload blob -f artifact $BLOB_URI) && echo "$BLOB_URI_DIGEST"
Uploading file from [artifact] to [ttl.sh/my-artifact-f42c22e0:5m] with media type [text/plain]
File [artifact] is available directly at [ttl.sh/v2/my-artifact-f42c22e0/blobs/sha256:c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626]
Uploaded image to:
ttl.sh/my-artifact-f42c22e0@sha256:790d47850411e902aabebc3a684eeb78fcae853d4dd6e1cc554d70db7f05f99f
```
ユーザーは、curl や wget などの標準ツールを使用して、「direct」URL からダウンロードできます:
```shell
$ curl -L ttl.sh/v2/$BLOB_NAME/blobs/sha256:$BLOB_SUM > artifact-fetched
```
ダイジェストはURLに直接埋め込まれているので、それも確認できます：
```shell
$ cat artifact-fetched | shasum -a 256
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626 -
```
通常の `cosign sign` コマンドとフラグで署名できます:
```shell
$ cosign sign --key cosign.key $BLOB_URI_DIGEST
Enter password for private key:
Pushing signature to: ttl.sh/my-artifact-f42c22e0
```
いつも通り、署名するイメージは必ずダイジェストで参照し、誤ったものに署名しないようにしてください！
#### Tekton Bundles
[Tekton](https://tekton.dev) バンドルは OCI レジストリ内でアップロードおよび管理できます。
仕様は[こちら](https://tekton.dev/docs/pipelines/tekton-bundle-contracts/)です。
これは、`cosign` で署名および検証もできることを意味します。
Tekton Bundles は現在 [tkn cli](https://github.com/tektoncd/cli) でアップロードできますが、将来的にこのサポートを
`cosign` に追加する可能性があります。
```shell
$ tkn bundle push us.gcr.io/dlorenc-vmtest2/pipeline:latest -f task-output-image.yaml
Creating Tekton Bundle:
- Added TaskRun: to image
Pushed Tekton Bundle to us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155
$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155
Enter password for private key:
tlog entry created with index: 5086
Pushing signature to: us.gcr.io/dlorenc-vmtest2/demo:sha256-124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155.sig
```
#### WASM
Web Assembly Modules は、この[仕様](https://github.com/solo-io/wasm/tree/master/spec)を使用して OCI レジストリに保存することもできます。
Cosign は `cosign wasm upload` コマンドを使用してこれらをアップロードできます:
```shell
$ cosign upload wasm -f hello.wasm us.gcr.io/dlorenc-vmtest2/wasm
$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/wasm@sha256:9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812
Enter password for private key:
tlog entry created with index: 5198
Pushing signature to: us.gcr.io/dlorenc-vmtest2/wasm:sha256-9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812.sig
```
#### eBPF
[eBPF](https://ebpf.io) モジュールは、この[仕様](https://github.com/solo-io/bumblebee/tree/main/spec)を使用して OCI レジストリに保存することもできます。
以下のイメージは `bee` ツールを使用してビルドされました。詳細は[こちら](https://github.com/solo-io/bumblebee/)をご覧ください。
Cosign は、他の OCI イメージと同様にこれらのイメージに署名できます。
```shell
$ bee build ./examples/tcpconnect/tcpconnect.c localhost:5000/tcpconnect:test
$ bee push localhost:5000/tcpconnect:test
$ cosign sign --key cosign.key localhost:5000/tcpconnect@sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6
Enter password for private key:
Pushing signature to: localhost:5000/tcpconnect
$ cosign verify --key cosign.pub localhost:5000/tcpconnect:test
Verification for localhost:5000/tcpconnect:test --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
[{"critical":{"identity":{"docker-reference":"localhost:5000/tcpconnect"},"image":{"docker-manifest-digest":"sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6"},"type":"cosign container image signature"},"optional":null}]
```
#### In-Toto アテステーション
Cosign は [in-toto](https://in-toto.io) アテステーションも組み込みでサポートしています。
これらの仕様は[こちら](https://github.com/in-toto/attestation)で定義されています。
以下のコマンドを使用して、ローカルの述語ファイルからアテステーションを作成し署名できます:
```shell
$ cosign attest --predicate <file> --key cosign.key $IMAGE_URI_DIGEST
```
標準的な鍵管理システムはすべてサポートされています。
ペイロードは、[こちら](https://github.com/secure-systems-lab/dsse)で定義されているDSSE署名仕様を使用して署名されます。
検証するには:
```shell
$ cosign verify-attestation --key cosign.pub $IMAGE_URI
```
## 詳細な使用方法
詳細については、[使用法ドキュメント](https://docs.sigstore.dev/cosign/signing/overview/)を参照してください。
## ハードウェアベースのトークン
ハードウェアで `cosign` を使用する方法については、[ハードウェアトークンのドキュメント](https://docs.sigstore.dev/cosign/key_management/hardware-based-tokens/)を参照してください。
## レジストリサポート
`cosign` はレジストリとのやり取りに [go-containerregistry](https://github.com/google/go-containerregistry) を使用しており、一般的に優れた互換性がありますが、一部のレジストリには癖がある場合があります。
現在、`cosign` は以下のレジストリに対してテストされ、動作しています:
* AWS Elastic Container Registry
* GCP の Artifact Registry および Container Registry
* Docker Hub
* Azure Container Registry
* JFrog Artifactory Container Registry
* CNCF distribution/distribution Registry
* GitLab Container Registry
* GitHub Container Registry
* CNCF Harbor Registry
* Digital Ocean Container Registry
* Sonatype Nexus Container Registry
* Alibaba Cloud Container Registry
* Red Hat Quay Container Registry 3.6+ / Red Hat quay.io
* Elastic Container Registry
* IBM Cloud Container Registry
* Cloudsmith Container Registry
* CNCF zot Registry
* OVHcloud Managed Private Registry
私たちは幅広いレジストリサポートを目指しています。[OCIメディアタイプ](https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md)をまだ完全にはサポートしていないレジストリ内のイメージに `sign` するには、`COSIGN_DOCKER_MEDIA_TYPES` を使用してレガシー相当のものにフォールバックする必要があるかもしれません。例えば:
```shell
COSIGN_DOCKER_MEDIA_TYPES=1 cosign sign --key cosign.key legacy-registry.example.com/my/image@$DIGEST
```
テストとバグ報告にご協力ください！
手順は[トラッキングイシュー](https://github.com/sigstore/cosign/issues/40)に記載されています。
## 注意事項
### 意図的に欠けている機能
`cosign`はECDSA-P256鍵のみを生成し、SHA256ハッシュを使用します。これはエフェメラルなキーレス署名とマネージドキー署名の両方に当てはまります。
鍵はPEMエンコードされたPKCS8形式で保存されます。
ただし、`cosign`を使用して、任意のアルゴリズムの任意の形式で署名を保存および取得できます。
### おそらく変更すべき点
#### ペイロード形式
`cosign`はペイロードに対してRed Hatの[simple signing](https://www.redhat.com/en/blog/container-image-signing)形式のみをサポートしています。
それは次のようになります:
```json
{
"critical": {
"identity": {
"docker-reference": "testing/manifest"
},
"image": {
"Docker-manifest-digest": "sha256:20be...fe55"
},
"type": "cosign container image signature"
},
"optional": {
"creator": "Bob the Builder",
"timestamp": 1458239713
}
}
```
**Note:** これは `cosign generate $IMAGE_URI_DIGEST` を使用してイメージ参照用に生成できます。
もし理にかなっていれば、このフォーマットを別のものに切り替えることも可能です。
一つの選択肢については https://github.com/notaryproject/notation/issues/40 を参照してください。
#### レジストリの詳細
`cosign` の署名は OCI レジストリ内に別個のオブジェクトとして保存され、「署名」対象のオブジェクトへの参照は弱いものにすぎません。
つまり、この関係はレジストリにとって不透明であり、イメージが削除されても署名が削除されたりガベージコレクションされたりすることは*ありません*。
同様に、ある環境から別の環境へ簡単にコピー**できます**が、これは自動ではありません。
複数の署名はリストに保存されますが、残念ながらこれは現時点では競合状態を引き起こします。
署名を追加するには、クライアントが「読み取り-追加-書き込み」操作を調整するため、競合が発生した場合は最後の書き込みが優先されます。
##### レジストリの指定
`cosign` はデフォルトで、署名対象のイメージと同じリポジトリに署名を保存します。
署名用に別のリポジトリを指定するには、`COSIGN_REPOSITORY` 環境変数を設定します。
これにより、指定されたイメージ内のリポジトリが次のように置き換えられます:
```shell
$ export COSIGN_REPOSITORY=gcr.io/my-new-repo
$ cosign sign --key cosign.key $IMAGE_URI_DIGEST
```
そのため、`gcr.io/dlorenc-vmtest2/demo` の署名は `gcr.io/my-new-repo/demo:sha256-DIGEST.sig` に保存されます。
注: レジストリによっては「リポジトリ」に異なる形式を期待する場合があります。
* [GCR](https://cloud.google.com/container-registry) を使用する場合、上記の例のように `gcr.io/$REPO` のようなレジストリ名で十分です。
* [Artifact Registry](https://cloud.google.com/artifact-registry) を使用する場合、リポジトリだけでなく `$LOCATION-docker.pkg.dev/$PROJECT/$REPO/$STORAGE_IMAGE` のような完全なイメージ名を指定します。例えば、
```shell
$ export COSIGN_REPOSITORY=us-docker.pkg.dev/my-new-repo/demo
$ cosign sign --key cosign.key $IMAGE_URI_DIGEST
```
`sha256-DIGEST` は `gcr.io/dlorenc-vmtest2/demo` のダイジェストと一致します。Artifact Registry では、`$LOCATION-docker.pkg.dev/$PROJECT/$REPO` のようなリポジトリだけを指定しても機能しません。
## 署名仕様
`cosign` は [minisign](https://jedisct1.github.io/minisign/) や
[signify](https://www.openbsd.org/papers/bsdcan-signify.html) のようなツールに触発されています。
生成された秘密鍵は PEM 形式で保存されます。
鍵は scrypt を KDF として、nacl/secretbox を暗号化に使用してパスワードで暗号化されます。
PEM ヘッダーは `ENCRYPTED SIGSTORE PRIVATE KEY` です:
```shell
-----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY-----
...
-----END ENCRYPTED SIGSTORE PRIVATE KEY-----
```
公開鍵は、`PUBLIC KEY` というヘッダーを持つ PEM エンコードされた標準 PKIX 形式でディスクに保存されます。
```
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELigCnlLNKgOglRTx1D7JhI7eRw99
QolE9Jo4QUxnbMy5nUuBL+UZF9qqfm/Dg1BNeHRThHzWh2ki9vAEgWEDOw==
-----END PUBLIC KEY-----
```
## ストレージ仕様
`cosign` は署名を OCI レジストリに保存し、署名インデックスを特定するための命名規則（署名対象の sha256 に基づくタグ）を使用します。
<p align="center">
<img src="https://raw.githubusercontent.com/sigstore/cosign/HEAD/images/signatures.dot.svg" />
</p>
`reg.example.com/ubuntu@sha256:703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715` の署名は `reg.example.com/ubuntu:sha256-703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715.sig` に配置されます。
おおよそ（ホスト名のポートを無視して）：署名インデックスを見つけるには `s/:/-/g` および `s/@/:/g` を使用します。
この戦略に関するいくつかの注意点については、[競合状態](#registry-details)を参照してください。
代替実装としては、透明性ログ、ローカルファイルシステム、別のリポジトリレジストリ、署名インデックスへの明示的な参照、新しいレジストリ API、grafeas などを使用することが考えられます。
### 署名対象
`cosign` は現在、レジストリに「マニフェスト」として保存されたアーティファクトに対してのみ機能します。
提案されているメカニズムは、任意のものを署名するのに十分な柔軟性があります。
### KMS サポート
`cosign` は、キーの生成と署名に KMS プロバイダーを使用することをサポートしています。
現在、cosign は Hashicorp Vault、AWS KMS、GCP KMS、Azure Key Vault をサポートしており、将来的にはさらに多くのサポートを希望しています！
追加の KMS プロバイダーは、[OVHcloud KMS](https://github.com/ovh/sigstore-kms-ovhcloud) などの外部プラグインとして利用可能です。
詳細については、[KMS ドキュメント](https://docs.sigstore.dev/cosign/key_management/overview/)を参照してください。
### OCI アーティファクト
[oras](https://github.com/deislabs/oras) を使用してアーティファクトをレジストリにプッシュします（この場合、`cosign` 自体です！）：
```shell
$ oras push us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact ./cosign
Uploading f53604826795 cosign
Pushed us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact
Digest: sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef
```
では、署名しましょう！もちろん `cosign` を使います：
```shell
$ cosign sign --key cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact@sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact:sha256-551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef.sig
```
最後に、`cosign` を再度 `cosign` で検証します:
```shell
$ cosign verify --key cosign.pub us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact@sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The claims were present in the transparency log
- The signatures were integrated into the transparency log when the certificate was valid
- The signatures were verified against the specified public key
- The code-signing certificate was verified using trusted certificate authority certificates
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef"},"Type":"cosign container image signature"},"Optional":null}
```
## FAQ
### Notary v2 を使わないのはなぜか
これに簡潔に答えるのは難しいです。
この投稿にはいくつかの比較が含まれています:
[Notary V2 and Cosign](https://medium.com/@dlorenc/notary-v2-and-cosign-b816658f044d)
他にも比較記事を見つけたら、ここに PR を送ってください。すべてリンクします。
### containers/image の署名を使わないのはなぜか
`containers/image` の署名は `cosign` に近く、ペイロード形式を再利用しています。
`cosign` が異なるのは、PGP ではなく ECDSA-P256 鍵で署名し、署名をレジストリに保存する点です。
### TUF を使わないのはなぜか?
このツールは TUF を補完するものであり、併用できると考えています。
まだ試していませんが、TUF のストレージにレジストリを再利用することもできると思います。
## 設計要件
* 署名の保存、クエリ、取得に外部サービスを使用しない
* 可能な限り多くのレジストリサポートを目指す
* すべてがレジストリ API 経由で動作すること
* PGP はまったく必須ではない。
* ユーザーはイメージのすべての署名を見つけられること
* 署名者はプッシュ後にイメージに署名できること
* 複数のエンティティがイメージに署名できること
* イメージへの署名がイメージを変更しないこと
* Pure-go 実装
## 今後のアイデア
### レジストリ API の変更
レジストリに物を保存するために使用している命名規則と read-modify-write 更新パターンは、
まあ、少し「ハッキー」です。
これらは今日利用可能な最良の(唯一の)現実的な選択肢だと思いますが、レジストリ API が
変わればこれらを改善できます。
### その他の型
`cosign` はレジストリ内のあらゆるものに署名できます。
これらの例では単一のイメージへの署名を示していますが、マルチプラットフォームの `Index` や
その他の種類のアーティファクトに署名することもできます。
これには Helm Charts、Tekton Pipelines、および現在 OCI レジストリを配布に使用している
---
[Read more](https://github.com/sigstore/cosign)