3 ms·

Functionality-wise this is a lot like docker-pushmi-pullyu[1] (which I wrote), except docker-pushmi-pullyu is a single relatively-simple shell script, and uses

Functionality-wise this is a lot like docker-pushmi-pullyu[1] (which I wrote), except docker-pushmi-pullyu is a single relatively-simple shell script, and uses the official registry image[2] rather than a custom server implementation. @psviderski I'm curious why you implemented your own registry for this, was it just to keep the image as small as possible? [1]: https://github.com/mkantor/docker-pushmi-pullyu https://github.com/mkantor/docker-pushmi-pullyu [2]: https://hub.docker.com/_/registry https://hub.docker.com/_/registry

matt_kantor 1y ago
After taking a closer look it seems the main conceptual difference between unregistry/docker-pussh and docker-pushmi-pullyu is that the former runs the temporary registry on the remote host, while the latter runs it locally. Although in both cases this is not something users should typically have to care about.
westurner 1y ago
Do docker-pussh or docker-pushmi-pullyu verify container image signatures and attestations? From "About Docker Content Trust (DCT)" https://docs.docker.com/engine/security/trust/ https://docs.docker.com/engine/security/trust/ : > Image consumers can enable DCT to ensure that images they use were signed. If a consumer enables DCT, they can only pull, run, or build with trusted images. export DOCKER_CONTENT_TRUST=1 cosign > verifying containers > verify attestation: https://docs.sigstore.dev/cosign/verifying/verify/#verify-attestation https://docs.sigstore.dev/cosign/verifying/verify/#verify-at... /? difference between docker content trust dct and cosign: https://www.google.com/search?q=difference+between+docker+content+trust+dct+and+cosign https://www.google.com/search?q=difference+between+docker+co...
- matt_kantor 1y ago
  docker-pushmi-pullyu does a vanilla `docker pull`[1] on the remote side, so you should be able to set `DOCKER_CONTENT_TRUST` in the remote environment to get whatever behavior you want (though admittedly I have not tested this). If there's desire for an option to specify `--disable-content-trust` during push and/or pull I'll happily add it. Please file an issue if this is something you want. [1]: https://github.com/mkantor/docker-pushmi-pullyu/blob/12d28932df0fda7c20cbe899820eaabce6b44997/docker-pushmi-pullyu#L168 https://github.com/mkantor/docker-pushmi-pullyu/blob/12d2893...
  - westurner 1y ago
    Should it be set in both the local and remote envs? What does it do if there's no signature? Do images built and signed with podman and cosign work with docker; are the artifact signatures portable across container CLIs docker, nerdctl, and podman?
    - westurner 1y ago
      From nerdctl/docs/cosign.md "Container Image Sign and Verify with cosign tool" https://github.com/containerd/nerdctl/blob/main/docs/cosign.md#container-image-sign-and-verify-with-cosign-tool https://github.com/containerd/nerdctl/blob/main/docs/cosign.... ; handily answering my own question aloud: Sign the container image while pushing, verify the signature on fetch/pull: # Sign the image with Keyless mode $ nerdctl push --sign=cosign devopps/hello-world # Sign the image and store the signature in the registry $ nerdctl push --sign=cosign --cosign-key cosign.key devopps/hello-world # Verify the image with Keyless mode $ nerdctl pull --verify=cosign --certificate-identity=name@example.com --certificate-oidc-issuer=https://accounts.example.com devopps/hello-world # You can not verify the image if it is not signed $ nerdctl pull --verify=cosign --cosign-key cosign.pub devopps/hello-world-bad
matt_kantor 1y ago
> I'm curious why you implemented your own registry for this Answering my own question: I think it's because you want to avoid the `docker pull` side of the equation (when possible) by having the registry's backing storage be the same as the engine's on the remote host.
- psviderski 1y ago
  Exactly, although my main motivation was to reduce the distinction between docker engine and docker registry. To make it possible for a user to push/pull to the docker daemon as if it was a registry, hence a registry wrapper. This is a prerequisite for what I want to build for uncloud, a clustering solution I’m developing. I want to make it possible to push an image to a cluster (store it right in the docker on one or multiple machines) and then run it on any machine in the cluster (pull from a machine that has the image if missing locally) eliminating a registry middleman.
  - matt_kantor 1y ago
    Very cool. As others have said: "push/pull to the docker daemon as if it was a registry" is how docker should always have worked. This is next level but I can imagine distributing resource usage across the cluster by pulling different layers from different peers concurrently.

matt_kantor 1y ago

After taking a closer look it seems the main conceptual difference between unregistry/docker-pussh and docker-pushmi-pullyu is that the former runs the temporary registry on the remote host, while the latter runs it locally. Although in both cases this is not something users should typically have to care about.

westurner 1y ago

Do docker-pussh or docker-pushmi-pullyu verify container image signatures and attestations? From "About Docker Content Trust (DCT)" https://docs.docker.com/engine/security/trust/ https://docs.docker.com/engine/security/trust/ : > Image consumers can enable DCT to ensure that images they use were signed. If a consumer enables DCT, they can only pull, run, or build with trusted images. export DOCKER_CONTENT_TRUST=1 cosign > verifying containers > verify attestation: https://docs.sigstore.dev/cosign/verifying/verify/#verify-attestation https://docs.sigstore.dev/cosign/verifying/verify/#verify-at... /? difference between docker content trust dct and cosign: https://www.google.com/search?q=difference+between+docker+content+trust+dct+and+cosign https://www.google.com/search?q=difference+between+docker+co...

matt_kantor 1y ago
docker-pushmi-pullyu does a vanilla `docker pull`[1] on the remote side, so you should be able to set `DOCKER_CONTENT_TRUST` in the remote environment to get whatever behavior you want (though admittedly I have not tested this). If there's desire for an option to specify `--disable-content-trust` during push and/or pull I'll happily add it. Please file an issue if this is something you want. [1]: https://github.com/mkantor/docker-pushmi-pullyu/blob/12d28932df0fda7c20cbe899820eaabce6b44997/docker-pushmi-pullyu#L168 https://github.com/mkantor/docker-pushmi-pullyu/blob/12d2893...
- westurner 1y ago
  Should it be set in both the local and remote envs? What does it do if there's no signature? Do images built and signed with podman and cosign work with docker; are the artifact signatures portable across container CLIs docker, nerdctl, and podman?
  - westurner 1y ago
    From nerdctl/docs/cosign.md "Container Image Sign and Verify with cosign tool" https://github.com/containerd/nerdctl/blob/main/docs/cosign.md#container-image-sign-and-verify-with-cosign-tool https://github.com/containerd/nerdctl/blob/main/docs/cosign.... ; handily answering my own question aloud: Sign the container image while pushing, verify the signature on fetch/pull: # Sign the image with Keyless mode $ nerdctl push --sign=cosign devopps/hello-world # Sign the image and store the signature in the registry $ nerdctl push --sign=cosign --cosign-key cosign.key devopps/hello-world # Verify the image with Keyless mode $ nerdctl pull --verify=cosign --certificate-identity=name@example.com --certificate-oidc-issuer=https://accounts.example.com devopps/hello-world # You can not verify the image if it is not signed $ nerdctl pull --verify=cosign --cosign-key cosign.pub devopps/hello-world-bad

matt_kantor 1y ago

> I'm curious why you implemented your own registry for this Answering my own question: I think it's because you want to avoid the `docker pull` side of the equation (when possible) by having the registry's backing storage be the same as the engine's on the remote host.

psviderski 1y ago
Exactly, although my main motivation was to reduce the distinction between docker engine and docker registry. To make it possible for a user to push/pull to the docker daemon as if it was a registry, hence a registry wrapper. This is a prerequisite for what I want to build for uncloud, a clustering solution I’m developing. I want to make it possible to push an image to a cluster (store it right in the docker on one or multiple machines) and then run it on any machine in the cluster (pull from a machine that has the image if missing locally) eliminating a registry middleman.
- matt_kantor 1y ago
  Very cool. As others have said: "push/pull to the docker daemon as if it was a registry" is how docker should always have worked. This is next level but I can imagine distributing resource usage across the cluster by pulling different layers from different peers concurrently.