The Problem With Using Naked Container Images Or The :latest tag

Let’s examine the following _very _common scenario: you have an application named xyz-app. The developers are constantly updating it, adding features, solving bugs, etc. Every two weeks or so, your CI/CD pipeline pushes the latest image to your Docker registry. By default, Docker registries tag the most recent version of an image with “latest”. If you pull the image without specifying a specific tag (naked image), you will automatically get the latest one. While this workflow sounds fine at first, it’s very risky. How do you know (and ensure) that your Kubernetes cluster is getting the newer image version? This simple diagram demonstrates what happens:

As per the diagram, the workflow is as follows:

1. After passing the tests, the latest code change is pushed to your CI/CD tool of choice.
2. The pipeline pushes the image to the container registry without specifying the tag, or explicitly appending “:latest” to the image name.
3. Finally, the pipeline contacts the cluster (perhaps through kubectl, helm, etc.) to make Kubernetes pull and use the new image. But how does Kubernetes know that you need to replace the image if the one it is already running is tagged latest, and the one you’re asking it to run it also _:latest _tagged?

Of course, one possible solution is to set imagePullPolicy to Always to force Kubernetes not to use the cached image and contact the container registry. But, then you need to kill the container so that the Deployment recreates it, and consequently pulls the latest image. Do we need to go that far just to deploy our newest code changes?

From the above undesirable scenario, it’s always strongly recommended that you use the appropriate image tag when building and pushing the container image. CI/CD tools make this very easy as they already provide unique values like the Git commit ID through environment variables. Following this best practice, we can re-depict our workflow as follows:

Now, it’s very straightforward to apply the actual latest image to your cluster by just patching the deployment with the changed image tag. The Deployment automatically pulls the newer image and, through rolling-updates, introduces the new application version with zero downtime.

However, this best practice is only valid if it’s applied. So, how do we ensure (and enforce) that no user or service will create a Pod (no matter which parent controller is used) that uses a naked or latest-tagged image? This is where OPA shines.

#devops #kubernetes #opa #open policy agent