(MVP) As a user I want to sync containers with its original signatures
* from sigstore
* from extentions API
(MVP) As a user on re-sync I want to sync new signatures
(MVP) As a user, I have signatures garbage collected with manifest deletion(from pulp)
(MVP) As a user when I remove manifest from a repo its signatures are removed as well https://pulp.plan.io/issues/9582
As a user I want to sign content:
As a user I want to invalidate(remove from repo) existing signatures:
(MVP) As a user, I have my signatures imported/exported together with the content
(MVP) As a user, I can push(create) signature via docker api extentions https://pulp.plan.io/issues/9511
Note that container/image(library) code checks for manifest exitense first i.e signature cannot exist without manifest
$ curl -X PUT --data @signature.json http://<registry_endpoint>:24817/extensions/v2/<namespace>/<repo-name>/signatures/<imagesha256digest>
cat signature.json
{
"version": 2,
"type": "atomic",
"name": "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
"content": "<base64 encoded signature>",
}
(MVP) As a user, I can get/list signatures via docker api extentions https://pulp.plan.io/issues/9513
GET /extensions/v2/<namespace>/<repo-name>/signatures/
GET /extensions/v2/<namespace>/<repo-name>/signatures/<imagesha256digest>
(MVP) As a user, I can get/list signatures via pulp api
As a user I can audit existing content and verify its' signature - https://pulp.plan.io/issues/9581 - wait until December 13 meeting, might get into MVP – not going into MVP
As a user when I copy manifest only manifest is copied by default
As a user when I copy signature, its manifest is copied as well
* NOTE: it does not make sense to cope signatures between the repos, docker-refence will stay same while base_path from distribution will differ
As a user I can add signatures to the repo but ensure such manifest is already present in the repo
As a user I can remove signatures from repos
EXD does not want to help with test content, so we are on our own.
Ideally, find repositories on registry.redhat.io which are tiny in size and are deprecated https://catalog.redhat.com/software/containers/search?include_deprecated=1 (so the repositories do not change) with the following content:
It would be great to find also:
class ContainerManifestSignature(Content):
PROTECTED_FROM_RECLAIM = False
TYPE = "signature"
name = models.CharField(max_length=255, db_index=True)
content = Binaryfield()
manifest_digest
type
creator
timestamp
manifest = models.ForeignKey(Manifest, on_delete=models.CASCADE)
key_id = models.CharField(max_length=255, db_index=True)
sha256_encrypted_file =
class Meta:
default_related_name = "%(app_label)s_%(model_name)s"
unique_together = ("sha256_encrypted_file", "manifest_digest")
uniqueness constraint - name
FK to Manifest
add a field that contains info about the key(fingerprint)?
Investigation part:
https://www.redhat.com/en/blog/container-image-signing
https://www.redhat.com/en/blog/signed-images-red-hat-container-catalog
https://access.redhat.com/articles/2750891
https://access.redhat.com/webassets/docker/content/sigstore
https://registry.redhat.io/containers/sigstore
https://access.redhat.com/articles/3116561
https://access.redhat.com/security/team/key
https://github.com/containers/image/blob/main/docs/containers-registries.d.5.md
https://github.com/containers/image/blob/main/docs/containers-registries.d.5.md#developing-and-signing-containers-staging-signatures
* one can have sigstore per namespace but not multiple sigstores per registry
* "file:/// signature storage can be both read and written, http/https only supports reading."
https://github.com/containers/image/blob/main/docs/signature-protocols.md
https://github.com/containers/image/blob/main/docs/containers-signature.5.md
* because that's the only supported today
https://github.com/openshift/origin/pull/12504/files
https://github.com/openshift/openshift-docs/pull/3556/files
https://github.com/mtrmac/image/commit/6c17ca34793b19accc3d278fc93ce68e9943fcb4 X-Registry-Supports-Signatures
* it supports only Atomic sig. type
Policy should be configured on the client, it gets applied on pull/run commands
https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md
https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md#examples
"hostname:5000/vendor/product": [
{ /* Require the image to be signed by the original vendor, using the vendor's repository location. */
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/path/to/vendor-pubkey.gpg",
"signedIdentity": {
"type": "exactRepository",
"dockerRepository": "vendor-hostname/product/repository"
}
},
{ /* Require the image to _also_ be signed by a local reviewer. */
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/path/to/reviewer-pubkey.gpg"
}
],
https://github.com/containers/podman/blob/main/docs/tutorials/image_signing.md
$ cat /etc/containers/registries.d/default.yaml | tail -10
docker:
localhost:24817:
#sigstore: http://inapprivateregistry.com/sigstore/
#sigstore: https://registry.redhat.io/containers/sigstore
sigstore-staging: file:///var/lib/containers/sigstore
registry.redhat.io:
sigstore: https://registry.redhat.io/containers/sigstore
#sigstore-staging: /mnt/nfs/privateregistry/sigstore
(pulp) [vagrant@pulp3-source-fedora34 ~]$
gpg2 –gen-key
gpg2 –armor –export –output mysignkey.gpg ipanova@redhat.com
gpg2 –list-keys
sudo -E GNUPGHOME=/home/vagrant/.gnupg podman push –log-level=debug –tls-verify=false –sign-by ipanova@redhat.com localhost:24817/alpine
https://github.com/sigstore/cosign
https://github.com/containers/skopeo/blob/main/docs/skopeo-standalone-sign.1.md
https://github.com/containers/skopeo/blob/main/docs/skopeo-standalone-verify.1.md
Cosign stores signatures as manifests, so no additional registry API needs to be created
Skopeo/Podman do not support cosign but there are plans to integrate with
Cosign signatures will not be deleted or garbage-collected when the image is deleted