Using :latest or Missing Image Tags

The Problem with :latest

The :latest tag in container images is mutable — it points to whatever was pushed most recently. Using it in Kubernetes manifests creates several problems.

Example with Tag Issues

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
        - name: web
          image: nginx:latest
          resources:
            limits:
              cpu: 200m
              memory: 128Mi
        - name: sidecar
          image: fluent/fluentd
          resources:
            limits:
              cpu: 100m
              memory: 64Mi

What the Validator Flags

• Warning: Container 'web' uses ':latest' tag. Pin to a specific version.
• Warning: Container 'sidecar' image 'fluent/fluentd' has no tag. This defaults to ':latest'.

Why Pin Image Versions

Problem	With :latest	With pinned version
Reproducibility	Different nodes may pull different images	Same image everywhere
Rollbacks	Cannot roll back to "previous latest"	kubectl rollout undo works
Auditing	No record of what version ran	Image tag in manifest is the record
Cache behavior	imagePullPolicy: Always required	Can use IfNotPresent
Security scanning	Can't track which vulnerabilities apply	Scan specific version

Best Practices for Image Tags

1. Use semantic versions: myapp:3.1.0, not myapp:latest
2. Use SHA digests for critical workloads: myapp@sha256:abc123...
3. Set imagePullPolicy: IfNotPresent when using pinned tags
4. Never use :latest in production manifests
5. Automate image updates with tools like Renovate or Flux image automation