search

GoogleContainerTools / kaniko

Build Container Images In Kubernetes
Apache License 2.0
14.88k stars 1.44k forks source link

New parameter to prevent retagging #2015

Open cedws opened 2 years ago

cedws commented 2 years ago

Overview

We would like a parameter (--no-retag?) that forces Kaniko to check if a tag already exists on the destination and if it does, aborts uploading to that particular destination. Preventing retagging is a fairly common thing people want to do to ensure their images aren't changed once they're running in production. On Kubernetes the image will of course be cached on nodes but that's not a guarantee and the imagePullPolicy might be always.

This could be a breaking change if somebody is currently using Kaniko with a role that is not able to list tags on a remote registry.

Why not disable it in the registry?

Most people who want to prevent retagging disable it in whatever registry they use. However, we use Google Artifact Registry which at this time doesn't support this. We tried using a custom IAM role without the artifactregistry.tags.update permission and yet Kaniko was able to move a tag from one layer to another.

We raised a ticket with Google Cloud support about this and they confirmed that artifactregistry.repositories.uploadArtifacts alone has the ability to upload layers and move tags. Therefore there is no way for us to prevent retagging in AR.

Why not pin pods to a particular image hash?

We could specify a tag and hash so that even if an image is retagged then the right layer is pulled. It would look something like:

ubuntu:20.04@sha256:dcc176d1ab45d154b767be03c703a35fe0df16cfb1cc7ea5dd3b6f9af99b6718

But the workflow of updating images would be more painful, and there's a subtle issue here. Docker seems to always prefer to pull by hash instead of the tag if it is specified. So in this case 20.04 could point to something completely different but Docker will still pull it as if the tag still points to this layer. It could be confusing if you don't watch out for this.

imjasonh commented 2 years ago

See https://github.com/GoogleContainerTools/kaniko/issues/958#issuecomment-1079191981

I don't consider this behavior that Kaniko should be responsible for. Similarly, docker build doesn't have any such flag with this behavior.

As mentioned throughout these comments, whatever workflow you're using to invoke Kaniko can also be used to conditionally not invoke Kaniko based on whatever conditions you want.

As for your other points, it should be the registry's responsibility to ensure immutable tags, not each individual tool that builds and pushes images. A user could still docker push or invoke other commands to push and retag images, even if Kaniko added this behavior.

When an image specifies both a tag and a digest, as you describe, the tag is basically just informational, and is ignored in favor of the digest SHA.

cedws commented 2 years ago

Sure, I completely agree that this shouldn't be Kaniko's responsibility. However I don't think AR will be the first or the last registry where disabling retagging is not possible.

We are mainly looking to prevent accidental retagging in CI rather than any kind of malicious retagging. In our setup it wouldn't be possible for a developer to use the Docker CLI to retag by hand because they don't have access.