<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

New! Magalix brings you the SaC (Security-as-Code) podcast. Listen now!

Exit icon Listen Now

Using the Latest Container Image Tag Can Cause Nightmares

DevOps Kubernetes opa Governance
Using the Latest Container Image Tag Can Cause Nightmares
DevOps Kubernetes opa Governance


When it comes to managing the behavior of your containers, Kubernetes does a good job of taking care of common use cases. My journey with Kubernetes started sometime in 2015, pre-1.0, so I’ve had my fair share of spinning up clusters and deploying containers.

A while back, I started in this environment where the build system would overwrite the latest image everytime containers were built. For those that have gone through a similar experience, you’ll probably know where I’m going with this, but for those that are currently doing this in practice, let me tell you that bad things can happen and why it becomes a nightmare to troubleshoot.

My Nightmare

The thing about nightmares is that even though they may only last a short time, they seem like they go on forever. In this particular situation, it definitely shared those characteristics. I was fairly new and unaware of the latest tag getting overwritten with every build. One evening, upon troubleshooting an unresponsive pod, I deleted it. No problem, it will come right back. What I didn’t notice was a new version of latest had downloaded and started.

Although the service came up properly, that version of the container was not ready for prime time. Upon testing the public endpoint, I was receiving various results. In a highly available situation where services are behind a load balancer, chances are one of the services in the pool is different from the rest. As I went through a series of various checks, I could not identify the problem. All the instances of this pod were using latest, and based on the logs, everything seemed normal. Why was one different?Using the Latest Container Image Tag Can Cause NightmaresAfter troubleshooting all the way back to the build system, I was finally able to identify what the issue was. I couldn’t alter the tags in the build system since I didn’t fully understand the downstream implications. Also, it wouldn’t have bought me anything since I was looking for an older version. Scaling down also wasn’t an option since it might scale down an instance of the correctly versioned pod. The only thing I could do was find the version of the source code, and manually rebuild that version to replace latest, forcing me to roll forward. I also got lucky picking the right version of the code.


When speaking with the rest of the team at Magalix I came to find out others have experienced similar stories like the one I just shared. We agreed that in order to save others from having to endure a similar experience, we should build a policy in our KubeAdvisor to detect a set tag (since no tag defaults to latest), and to ensure that tag isn’t set to latest. You definitely wouldn’t want to be in a similar situation as I was so leveraging Magalix to help you avoid the same mistakes that have been made in other environments.


KubeAdvisor was built with governance in mind. By enabling our out-of-the-box best practices, like our image_tag_policy, we can help you build and maintain a strong governance-as-code library.

Get Started

Comments and Responses

Related Articles

The Shared Security Model - Dividing Responsibilities

Understanding the Shared Cloud Security Model and causes behind common data breaches.

Read more
How to Prevent Non-Secure Container Images from Being Deployed with Policy-As-Code

Security is critical to business continuity. As such, DevOps teams must prevent non-secure container images from being deployed. But how do you do it?

Read more
Using Affinity with nodeSelector and Policy-As-Code, and Exclusions

In a Kubernetes cluster, you have to leverage policy-as-code to enforce Node Affinity using nodeSelector. But how do you do go about it? Learn more.

Read more