sigstore/cosignSignature de code et transparence pour les conteneurs et les binaires
<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
Signer des conteneurs OCI (et d'autres artefacts) en utilisant [Sigstore](https://sigstore.dev/) !
[](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 vise à rendre les signatures **une infrastructure invisible**.
Cosign prend en charge :
* La « signature sans clé » avec l'autorité de certification Fulcio du bien public Sigstore et le journal de transparence Rekor (par défaut)
* La signature matérielle et KMS
* La signature avec une paire de clés privée/publique chiffrée générée par cosign
* La signature, la vérification et le stockage de conteneurs dans un registre OCI.
* L'apport de votre propre PKI
## Info
`Cosign` est développé dans le cadre du projet [`sigstore`](https://sigstore.dev).
Nous utilisons également un [canal slack](https://sigstore.slack.com) !
Cliquez [ici](https://join.slack.com/t/sigstore/shared_invite/zt-47srvpyn6-j8Ek5hGBwKN32IjLw8BvYA) pour le lien d'invitation.
## Installation
Pour les installations Homebrew, Arch, Nix, GitHub Action et Kubernetes, consultez la [documentation d'installation](https://docs.sigstore.dev/cosign/system_config/installation/).
Pour les binaires Linux, macOS et Windows, consultez les [ressources de version GitHub](https://github.com/sigstore/cosign/releases/latest).
:rotating_light: Si vous téléchargez des versions de cosign depuis notre bucket GCS - veuillez consulter plus d'informations sur l'[avis de dépréciation](https://blog.sigstore.dev/cosign-releases-bucket-deprecation/) du 31 juillet 2023 :rotating_light:
## Installation pour les développeurs
Si vous disposez de Go 1.22+, vous pouvez configurer un environnement de développement :
```shell
$ git clone https://github.com/sigstore/cosign
$ cd cosign
$ go install ./cmd/cosign
$ $(go env GOPATH)/bin/cosign
```
## Contribution
Si vous souhaitez contribuer à `cosign`, veuillez lire la [documentation de contribution](https://github.com/sigstore/cosign/blob/main/CONTRIBUTING.md).
Le développement futur de Cosign sera axé sur la prochaine version majeure qui sera basée sur
[sigstore-go](https://github.com/sigstore/sigstore-go). Les mainteneurs se concentreront sur le développement de fonctionnalités au sein de
sigstore-go. Les contributions à sigstore-go, en particulier autour des clés apportées par l'utilisateur et de la signature, sont appréciées.
Veuillez consulter le [suivi des problèmes](https://github.com/sigstore/sigstore-go/issues) pour les bons premiers problèmes.
Cosign 2.x est une version stable et continuera de recevoir des mises à jour de fonctionnalités et des corrections de bugs périodiques. Les PR
de petite envergure et de petite taille sont les plus susceptibles d'être rapidement examinées.
Les PR qui modifient ou cassent significativement l'API ne seront pas acceptées. Les PR de taille importante mais qui n'introduisent pas
de changements cassants peuvent être acceptées, mais seront considérées comme de priorité inférieure aux PR dans sigstore-go.
## Dockerfile
Voici comment installer et utiliser cosign dans un Dockerfile via l'image ghcr.io/sigstore/cosign/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" ]
```
## Démarrage rapide
Ceci montre comment :
* signer une image de conteneur avec la méthode par défaut de « signature sans clé » basée sur l'identité (voir [la documentation pour plus d'informations](https://docs.sigstore.dev/cosign/signing/overview/))
* vérifier l'image de conteneur
* explorer des flux plus larges de signature/vérification de blobs sans clé dans le [Sigstore Cosign Quickstart](https://docs.sigstore.dev/quickstart/quickstart-cosign/)
### Signer un conteneur et stocker la signature dans le registre
Notez que vous devez toujours signer les images en fonction de leur digest (`@sha256:...`)
plutôt que d'un tag (`:latest`) car sinon vous risquez de signer quelque chose que vous
ne vouliez pas !
```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 vous demandera de vous authentifier via OIDC, où vous vous connecterez avec votre adresse e-mail.
En arrière-plan, cosign demandera un certificat de signature de code à l'autorité de certification Fulcio.
Le sujet du certificat correspondra à l'adresse e-mail avec laquelle vous vous êtes connecté.
Cosign stockera ensuite la signature et le certificat dans le journal de transparence Rekor, et téléversera la signature vers le registre OCI aux côtés de l'image que vous signez.
### Vérifier un conteneur
Pour vérifier l'image, vous devrez fournir le sujet de certificat attendu et l'émetteur de certificat via les options `--certificate-identity` et `--certificate-oidc-issuer` :
```
cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-issuer=$OIDC_ISSUER
```
Vous pouvez également passer une expression régulière pour les options d'identité de certificat et d'émetteur, `--certificate-identity-regexp` et `--certificate-oidc-issuer-regexp`.
### Vérifier un conteneur par rapport à une clé publique
Cette commande renvoie `0` si *au moins une* signature au format `cosign` pour l'image est trouvée
correspondant à la clé publique.
Consultez l'utilisation détaillée ci-dessous pour obtenir des informations et des mises en garde sur les autres formats de signature.
Toutes les charges utiles valides sont imprimées sur stdout, au format json.
Notez que ces charges utiles signées incluent le digest de l'image du conteneur, ce qui nous permet d'être
sûrs que ces signatures « détachées » couvrent la bonne image.
```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}
```
### Vérifier un conteneur dans un environnement isolé (air-gapped)
**Remarque :** Cette section est obsolète.
**Remarque :** La plupart des workflows de vérification nécessitent de demander périodiquement des clés de service à un dépôt TUF.
Pour la vérification hors ligne des signatures à l'aide de l'instance public-good, vous devrez récupérer le
fichier [trusted root](https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json) depuis le dépôt
TUF de production. Le contenu de ce fichier changera sans notification. En n'utilisant pas TUF, vous devrez
mettre en place votre propre mécanisme pour maintenir à jour votre copie hors ligne de ce fichier.
Cosign peut effectuer une vérification entièrement hors ligne en vérifiant un [bundle](https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md#properties) qui est généralement distribué sous forme d'annotation sur le manifeste de l'image.
Tant que cette annotation est présente, la vérification hors ligne peut être effectuée.
Cette annotation de bundle est toujours incluse par défaut pour la signature sans clé (keyless), donc la fonctionnalité par défaut `cosign sign` inclura tous les éléments nécessaires à la vérification hors ligne.
Pour vérifier une image dans un environnement isolé (air-gapped), l'image et les signatures doivent être disponibles localement sur le système de fichiers.
Une image peut être sauvegardée localement à l'aide de `cosign save` (notez que cette étape doit être effectuée avec une connexion réseau) :
```
cosign initialize # This will pull in the latest TUF root
cosign save $IMAGE_NAME --dir ./path/to/dir
```
Maintenant, dans un environnement isolé du réseau, cette image locale peut être vérifiée :
```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
```
Vous devrez fournir les valeurs attendues pour `$CERT_IDENTITY` et `$CERT_OIDC_ISSUER` afin de vérifier correctement cette image.
Si vous avez signé avec une paire de clés, la même commande fonctionnera, à condition que le matériel de clé publique soit présent localement :
```
cosign verify --key cosign.pub --offline --local-image ./path/to/dir
```
### Signature et vérification de blobs basées sur l'identité
Utilisez la signature de blobs sans clé (`cosign sign-blob` sans `--key`) et vérifiez par rapport à l'identité du signataire attendue :
```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"
```
### Dépannage
Si vous rencontrez des problèmes avec Cosign, assurez-vous d'abord que vous utilisez une version récente : le projet Cosign prend activement en charge la version la plus récente ainsi que la dernière version de la série v2.
#### Problèmes courants et solutions
1. La vérification échoue avec `failed to verify timestamps: threshold not met for verified log entry integrated timestamps: 0 < 1` : vous vérifiez peut-être une signature qui nécessite la prise en charge des horodatages RFC3161
* Mettez à niveau vers la version la plus récente de Cosign ou
* Avec Cosign 2.6.x, utilisez `--use-signed-timestamps`
1. La vérification échoue avec `no signatures found` : vous vérifiez peut-être une signature d'image qui nécessite la prise en charge du journal de transparence Rekor v2
* Mettez à niveau vers la version la plus récente de Cosign
1. La signature échoue avec des erreurs HTTP : la signature avec Cosign dépend de plusieurs services Sigstore. Réessayer en cas d'échec peut être une solution de contournement utile si l'un de ces services tombe en panne -- signaler des problèmes pour des échecs spécifiques est également apprécié
#### Mon problème est différent
Veuillez ouvrir une [issue](https://github.com/sigstore/cosign/issues/new/choose) ou poser votre question dans le [canal slack](#info).
## Travailler avec d'autres artefacts
Les registres OCI sont utiles pour stocker bien plus que de simples images de conteneurs !
`Cosign` inclut également quelques utilitaires pour publier des artefacts génériques, notamment des binaires, des scripts et des fichiers de configuration utilisant le protocole OCI.
Cette section montre comment tirer parti de ces fonctionnalités pour un système de distribution d'artefacts facile à utiliser, rétrocompatible et qui s'intègre bien avec le reste de Sigstore.
Consultez [la documentation](https://docs.sigstore.dev/cosign/signing/other_types/) pour plus d'informations.
### Blobs
Vous pouvez publier un artefact avec `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
```
Vos utilisateurs peuvent le télécharger depuis l'URL « direct » avec des outils standards comme curl ou wget :
```shell
$ curl -L ttl.sh/v2/$BLOB_NAME/blobs/sha256:$BLOB_SUM > artifact-fetched
```
Le digest est intégré directement dans l'URL, ils peuvent donc aussi le vérifier :
```shell
$ cat artifact-fetched | shasum -a 256
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626 -
```
Vous pouvez le signer avec la commande et les options habituelles `cosign sign` :
```shell
$ cosign sign --key cosign.key $BLOB_URI_DIGEST
Enter password for private key:
Pushing signature to: ttl.sh/my-artifact-f42c22e0
```
Comme toujours, assurez-vous de référencer toutes les images que vous signez par leur digest pour être sûr de ne pas signer la mauvaise chose !
#### Tekton Bundles
Les bundles [Tekton](https://tekton.dev) peuvent être téléversés et gérés dans un registre OCI.
La spécification est disponible [ici](https://tekton.dev/docs/pipelines/tekton-bundle-contracts/).
Cela signifie qu'ils peuvent également être signés et vérifiés avec `cosign`.
Les Tekton Bundles peuvent actuellement être téléversés avec le [tkn cli](https://github.com/tektoncd/cli), mais nous pourrions ajouter ce support à
`cosign` à l'avenir.
```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
Les modules Web Assembly peuvent également être stockés dans un registre OCI, en utilisant cette [spécification](https://github.com/solo-io/wasm/tree/master/spec).
Cosign peut les téléverser à l'aide de la commande `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
Les modules [eBPF](https://ebpf.io) peuvent également être stockés dans un registre OCI, en utilisant cette [spécification](https://github.com/solo-io/bumblebee/tree/main/spec).
L'image ci-dessous a été construite à l'aide de l'outil `bee`. Plus d'informations sont disponibles [ici](https://github.com/solo-io/bumblebee/)
Cosign peut ensuite signer ces images comme n'importe quelle autre image 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}]
```
#### Attestations In-Toto
Cosign dispose également d'une prise en charge intégrée des attestations [in-toto](https://in-toto.io).
La spécification de celles-ci est définie [ici](https://github.com/in-toto/attestation).
Vous pouvez en créer et signer une à partir d'un fichier de prédicat local à l'aide des commandes suivantes :
```shell
$ cosign attest --predicate <file> --key cosign.key $IMAGE_URI_DIGEST
```
Tous les systèmes de gestion de clés standard sont pris en charge.
Les payloads sont signés à l'aide de la spécification de signature DSSE, définie [ici](https://github.com/secure-systems-lab/dsse).
Pour vérifier :
```shell
$ cosign verify-attestation --key cosign.pub $IMAGE_URI
```
## Utilisation détaillée
Consultez la [documentation d'utilisation](https://docs.sigstore.dev/cosign/signing/overview/) pour plus d'informations.
## Jetons matériels
Consultez la [documentation sur les jetons matériels](https://docs.sigstore.dev/cosign/key_management/hardware-based-tokens/) pour savoir comment utiliser `cosign` avec du matériel.
## Prise en charge des registres
`cosign` utilise [go-containerregistry](https://github.com/google/go-containerregistry) pour les interactions avec les registres, ce qui offre généralement une excellente compatibilité, mais certains registres peuvent présenter des particularités.
Aujourd'hui, `cosign` a été testé et fonctionne avec les registres suivants :
* AWS Elastic Container Registry
* GCP's Artifact Registry and Container Registry
* Docker Hub
* Azure Container Registry
* JFrog Artifactory Container Registry
* The CNCF distribution/distribution Registry
* GitLab Container Registry
* GitHub Container Registry
* The 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
* The CNCF zot Registry
* OVHcloud Managed Private Registry
Nous visons une large prise en charge des registres. Pour `sign` des images dans des registres qui ne prennent pas encore entièrement en charge les [types de médias OCI](https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md), il peut être nécessaire d'utiliser `COSIGN_DOCKER_MEDIA_TYPES` pour revenir à des équivalents hérités. Par exemple :
```shell
COSIGN_DOCKER_MEDIA_TYPES=1 cosign sign --key cosign.key legacy-registry.example.com/my/image@$DIGEST
```
Veuillez nous aider à tester et à signaler les bugs si vous rencontrez des problèmes !
Les instructions se trouvent dans le [ticket de suivi](https://github.com/sigstore/cosign/issues/40).
## Mises en garde
### Fonctionnalités intentionnellement absentes
`cosign` génère uniquement des clés ECDSA-P256 et utilise des hachages SHA256, à la fois pour la signature éphémère sans clé et la signature avec clé gérée.
Les clés sont stockées au format PKCS8 encodé en PEM.
Cependant, vous pouvez utiliser `cosign` pour stocker et récupérer des signatures dans n'importe quel format, à partir de n'importe quel algorithme.
### Choses qui devraient probablement changer
#### Formats de charge utile
`cosign` prend uniquement en charge le format [simple signing](https://www.redhat.com/en/blog/container-image-signing) de Red Hat pour les charges utiles.
Cela ressemble à :
```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
}
}
```
**Remarque :** Ceci peut être généré pour une référence d'image en utilisant `cosign generate $IMAGE_URI_DIGEST`.
Je suis prêt à changer ce format pour autre chose si cela a du sens.
Voir https://github.com/notaryproject/notation/issues/40 pour une option.
#### Détails du registre
Les signatures `cosign` sont stockées sous forme d'objets séparés dans le registre OCI, avec seulement une
référence faible vers l'objet qu'elles « signent ».
Cela signifie que cette relation est opaque pour le registre, et les signatures *ne seront pas* supprimées
ni ramassées par le garbage collector lorsque l'image est supprimée.
De même, elles **peuvent** facilement être copiées d'un environnement à un autre, mais cela n'est pas
automatique.
Plusieurs signatures sont stockées dans une liste, ce qui constitue malheureusement une condition de course aujourd'hui.
Pour ajouter une signature, les clients orchestrent une opération « lecture-ajout-écriture », donc la dernière écriture
l'emportera en cas de contention.
##### Spécification du registre
`cosign` stockera par défaut les signatures dans le même dépôt que l'image qu'il signe.
Pour spécifier un dépôt différent pour les signatures, vous pouvez définir la variable d'environnement `COSIGN_REPOSITORY`.
Cela remplacera le dépôt dans l'image fournie comme ceci :
```shell
$ export COSIGN_REPOSITORY=gcr.io/my-new-repo
$ cosign sign --key cosign.key $IMAGE_URI_DIGEST
```
Ainsi, la signature de `gcr.io/dlorenc-vmtest2/demo` sera stockée dans `gcr.io/my-new-repo/demo:sha256-DIGEST.sig`.
Remarque : différents registres peuvent attendre différents formats pour le « repository ».
* Pour utiliser [GCR](https://cloud.google.com/container-registry), un nom de registre
comme `gcr.io/$REPO` suffit, comme dans l'exemple ci-dessus.
* Pour utiliser [Artifact Registry](https://cloud.google.com/artifact-registry),
spécifiez un nom d'image complet comme
`$LOCATION-docker.pkg.dev/$PROJECT/$REPO/$STORAGE_IMAGE`, et non pas seulement un
repository. Par exemple,
```shell
$ export COSIGN_REPOSITORY=us-docker.pkg.dev/my-new-repo/demo
$ cosign sign --key cosign.key $IMAGE_URI_DIGEST
```
où le `sha256-DIGEST` correspondra au digest pour
`gcr.io/dlorenc-vmtest2/demo`. Spécifier uniquement un dépôt comme
`$LOCATION-docker.pkg.dev/$PROJECT/$REPO` ne fonctionnera pas dans Artifact Registry.
## Spécification de signature
`cosign` s'inspire d'outils comme [minisign](https://jedisct1.github.io/minisign/) et
[signify](https://www.openbsd.org/papers/bsdcan-signify.html).
Les clés privées générées sont stockées au format PEM.
Les clés sont chiffrées sous un mot de passe en utilisant scrypt comme KDF et nacl/secretbox pour le chiffrement.
Elles ont un en-tête PEM de `ENCRYPTED SIGSTORE PRIVATE KEY` :
```shell
-----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY-----
...
-----END ENCRYPTED SIGSTORE PRIVATE KEY-----
```
Les clés publiques sont stockées sur disque au format PKIX standard encodé en PEM avec un en-tête `PUBLIC KEY`.
```
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELigCnlLNKgOglRTx1D7JhI7eRw99
QolE9Jo4QUxnbMy5nUuBL+UZF9qqfm/Dg1BNeHRThHzWh2ki9vAEgWEDOw==
-----END PUBLIC KEY-----
```
## Spécification de stockage
`cosign` stocke les signatures dans un registre OCI, et utilise une convention de nommage (tag basé
sur le sha256 de ce que nous signons) pour localiser l'index de signature.
<p align="center">
<img src="https://raw.githubusercontent.com/sigstore/cosign/HEAD/images/signatures.dot.svg" />
</p>
`reg.example.com/ubuntu@sha256:703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715` a ses signatures situées à `reg.example.com/ubuntu:sha256-703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715.sig`
En gros (en ignorant les ports dans le nom d'hôte) : `s/:/-/g` et `s/@/:/g` pour trouver l'index de signature.
Voir [Conditions de concurrence](#registry-details) pour quelques mises en garde concernant cette stratégie.
Des implémentations alternatives pourraient utiliser des journaux de transparence, un système de fichiers local, un registre de dépôt séparé,
une référence explicite à un index de signature, une nouvelle API de registre, grafeas, etc.
### Sujets de signature
`cosign` ne fonctionne aujourd'hui que pour les artefacts stockés sous forme de « manifests » dans le registre.
Le mécanisme proposé est suffisamment flexible pour prendre en charge la signature d'éléments arbitraires.
### Prise en charge de KMS
`cosign` prend en charge l'utilisation d'un fournisseur KMS pour générer et signer des clés.
Actuellement, cosign prend en charge Hashicorp Vault, AWS KMS, GCP KMS, Azure Key Vault et nous espérons en prendre en charge davantage à l'avenir !
Des fournisseurs KMS supplémentaires sont disponibles sous forme de plugins externes, tels que [OVHcloud KMS](https://github.com/ovh/sigstore-kms-ovhcloud).
Voir la [documentation KMS](https://docs.sigstore.dev/cosign/key_management/overview/) pour plus de détails.
### Artefacts OCI
Poussez un artefact vers un registre à l'aide de [oras](https://github.com/deislabs/oras) (dans ce cas, `cosign` lui-même !) :
```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
```
Signez-le maintenant ! Avec `cosign` bien sûr :
```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
```
Enfin, vérifiez `cosign` avec `cosign` à nouveau :
```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
### Pourquoi ne pas utiliser Notary v2
Il est difficile de répondre à cela brièvement.
Ce billet contient quelques comparaisons :
[Notary V2 and Cosign](https://medium.com/@dlorenc/notary-v2-and-cosign-b816658f044d)
Si vous trouvez d'autres billets de comparaison, veuillez envoyer une PR ici et nous les lierons tous.
### Pourquoi ne pas utiliser la signature containers/image
La signature `containers/image` est proche de `cosign`, et nous réutilisons les formats de payload.
`cosign` diffère en ce qu'il signe avec des clés ECDSA-P256 au lieu de PGP, et stocke
les signatures dans le registre.
### Pourquoi ne pas utiliser TUF ?
Je pense que cet outil est complémentaire à TUF, et qu'ils peuvent être utilisés ensemble.
Je n'ai pas encore essayé, mais je pense que nous pouvons également réutiliser un registre pour le stockage TUF.
## Exigences de conception
* Aucun service externe pour le stockage, l'interrogation ou la récupération des signatures
* Nous visons un support maximal des registres
* Tout doit fonctionner via l'API du registre
* PGP ne doit pas être requis du tout.
* Les utilisateurs doivent pouvoir trouver toutes les signatures d'une image
* Les signataires peuvent signer une image après le push
* Plusieurs entités peuvent signer une image
* Signer une image ne modifie pas l'image
* Implémentation pure-go
## Idées futures
### Modifications de l'API du registre
La convention de nommage et les modèles de mise à jour lecture-modification-écriture que nous utilisons pour stocker des choses dans
un registre sont un peu, disons, « bricolés ».
Je pense qu'ils sont la meilleure (seule) option réelle disponible aujourd'hui, mais si l'API du registre
change, nous pouvons les améliorer.
### Autres types
`cosign` peut signer n'importe quoi dans un registre.
Ces exemples montrent la signature d'une seule image, mais vous pouvez aussi signer un `Index` multi-plateforme,
ou tout autre type d'artefact.
Cela inclut les Helm Charts, les Tekton Pipelines, et tout ce qui utilise actuellement les registres OCI
pour la distribution.
Cela signifie également que de nouveaux types d'artefacts peuvent être téléversés dans un registre et signés.
Un type intéressant à stocker et signer serait les dépôts TUF.
Je n'ai pas encore essayé, mais je suis assez certain que TUF pourrait être implémenté au-dessus de cela.
### Signature de tags
Les signatures `cosign` protègent les digests des objets stockés dans un registre.
Le support optionnel des `annotations` (via le flag `-a` de `cosign sign`) peut être utilisé pour ajouter des
données supplémentaires au payload qui est signé et protégé par la signature.
Un cas d'usage pourrait être de signer une correspondance tag->digest.
Si vous souhaitez attester qu'un tag spécifique (ou un ensemble de tags) doit pointer vers un digest, vous pouvez
exécuter quelque chose comme :
```shell
$ docker push $IMAGE_URI
The push refers to repository [dlorenc/demo]
994393dc58e7: Pushed
5m: digest: sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 size: 528
$ TAG=sign-me
$ cosign sign --key cosign.key -a tag=$TAG $IMAGE_URI_DIGEST
Enter password for private key:
Pushing signature to: dlorenc/demo:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870.sig
```
Ensuite, vous pouvez vérifier que la correspondance tag->digest est également couverte dans la signature, en utilisant le flag `-a` de `cosign verify`.
Cet exemple vérifie que le digest `$TAG` qui pointe vers (`sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870`)
a été signé, **et aussi** que l'annotation `tag` a la valeur `sign-me` :
```shell
$ cosign verify --key cosign.pub -a tag=$TAG $IMAGE_URI | jq .
{
"Critical": {
"Identity": {
"docker-reference": ""
},
"Image": {
"Docker-manifest-digest": "97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"
},
"Type": "cosign container image signature"
},
"Optional": {
"tag": "sign-me"
}
}
```
Des horodatages pourraient également être ajoutés ici, afin de mettre en œuvre une prévention des attaques de type freeze-attack à la manière de TUF.
### Signature de l'image/des couches de base
Là encore, `cosign` peut signer n'importe quoi dans un registre.
---
[Read more](https://github.com/sigstore/cosign)