Sign local container images before they are pushed to registries #777
Description
Is your feature request related to a problem?
Background
Nowadays, in order to sign container images, users must first push the images to a registry. However, registries are not within the trust boundary of Notation, as outlined in the threat model. If a registry is compromised, attackers can tamper with container images during the short period between when they are pushed to the registry and when they are signed by users. From the perspective of image consumers, the image can be verified against the signature successfully, but it may still be malicious. This is a serious security issue that cannot be easily detected.
Notation supports an experimental feature that allows users to sign a local image in OCI layout format. However, this is not how most users build their container images. Most users build container images using Docker Engine, including Docker CLI and dockerd as the daemon. The container images built on a local machine are not in the format of OCI layout; instead, they are in Docker’s own format. Docker Engine also supports containerd as the daemon, and the image built on a local machine is in the format of OCI layout with minor differences. However, supporting containerd is not yet a stable feature.
Scenario
A software engineer wants to sign local container images built by docker build before pushing images to a registry. Verification of the image should be the same workflow for signing and verifying images stored in OCI complaint registry.
What solution do you propose?
docker save command can save a local image into a tar file, however, it is in the format of docker own, not OCI layout or other standard format. The tar file is not the one that docker push command pushes to the registry. So, if we sign local images created by docker save command, the digest is different from digest of manifest of the image that is pushed to the container registry. To sign tar file created by docker save, and verify it before docker load, I would suggest considering feature sign and verify arbitrary file.
My proposal is to create an official docker plugin to generate an OCI descriptor and sign the descriptor. Here is the experience.
- Built a container image using command
docker build/buildx
docker build -t localhost:5001/net-monitor:v1 https://github.com/wabbit-networks/net-monitor.git#main - List the container images on local machine to confirm the image was built
docker images - Run docker plugin named
descriptorto generate a OCI descriptor for the container image.
docker descriptor generate localhost:5001/net-monitor:v1-o net-monitor.json - Sign the descriptor
notation sign --descriptor net-monitor.json --output-signature digest.sig - Push the local container image to an OCI compliant registry
docker push localhost:5001/net-monitor:v1 - Push the signature
notation push digest.sig localhost:5001/net-monitor:v1 - List the signature to confirm it is existing and associated with the image
notation list
What alternatives have you considered?
Use a tool to convert local docker images to an OCI layout, and then sign the OCI layout as the experimental feature.
Any additional context?
No response