Kubernetes v1.33 fixes private image reuse across pods

In a post on the Kubernetes Blog in May 2025, maintainers Ben Petersen and Stanislav Láznička described a critical security adjustment in Kubernetes v1.33. The update addresses a decade-old issue where pods could inadvertently access private container images pulled by other pods on the same node without proper authorization.

What happened

For over ten years, Kubernetes users have encountered a subtle but significant security gap related to the imagePullPolicy: IfNotPresent setting. This policy is designed to optimize performance by using a locally cached image if it exists, rather than pulling it from the registry every time. However, this optimization previously ignored authentication boundaries between different pods scheduled on the same node.

The core problem arose when Pod A, authorized with specific credentials via an imagePullSecret, pulled a private image onto a node. If Pod B, residing in a different namespace and lacking any valid credentials for that private repository, was subsequently scheduled to the same node with the IfNotPresent policy, the Kubelet would allow it to use the cached image. Pod B had never been authorized to pull the image, yet it gained access simply because the binary layers were already present on the disk. This behavior violated the principle of least privilege and created a potential supply chain security risk within clusters.

With the release of Kubernetes v1.33, SIG Auth and SIG Node have introduced a fix to enforce credential verification even when images are cached. The new behavior ensures that a pod can only use a locally present private image if it provides credentials that match those used during the initial pull. This change closes the loophole while maintaining the performance benefits of local caching for authorized workloads.

How it works

The solution relies on persistent, file-based caches maintained by the Kubelet on each node. When a pod requests an image that is not currently on the node, the Kubelet records the intent to pull. It then extracts credentials from the referenced Kubernetes Secret and performs the pull from the private registry. Upon success, the Kubelet stores a record of this event, including a hash of the credentials used and the source Secret identifier.

When a subsequent pod requests the same image, the Kubelet checks its local cache. Instead of blindly serving the cached image, it compares the credentials provided by the new pod against the stored records. If the credential hash or the source Secret matches a previous successful pull, the pod is granted access to the cached image without re-downloading data. If there is no match, the Kubelet attempts to pull the image from the remote registry using the new credentials, triggering the standard authorization flow. This mechanism ensures that only pods with valid, matching credentials can reuse cached private images.

Key details

• The fix addresses issue 18787, a security caveat present in Kubernetes for over ten years.
• The feature is available as an alpha release in Kubernetes v1.33.
• Users must enable the KubeletEnsureSecretPulledImages feature gate on their Kubelets to activate the new behavior.
• Pods using the same credential or source Secret do not need to re-authenticate, preserving performance.
• The imagePullPolicy: Never policy now also requires credential verification for private images already on the node.
• Future plans include integrating with Projected service account tokens and adding support for credential expirations.

Why it matters

For software engineers and platform teams, this change strengthens cluster isolation without requiring drastic operational shifts. Previously, many organizations enforced imagePullPolicy: Always as a workaround to ensure that every pod performed an authentication check with the registry. While secure, this approach placed the image registry in the critical path for every pod startup, scale-up, or restart, increasing latency and dependency on external services. The new verification mechanism allows teams to safely use IfNotPresent, reducing registry load and improving startup times while maintaining strict security controls.

This update also simplifies multi-tenant cluster management. In environments where multiple teams share nodes, the risk of one team accidentally accessing another team’s private images is now mitigated at the Kubelet level. Platform engineers can rely on the infrastructure to enforce access policies rather than depending solely on network policies or admission controllers to prevent unauthorized image usage. This shift aligns Kubernetes behavior more closely with user expectations regarding security and isolation.

What you can do

• Upgrade your test clusters to Kubernetes v1.33 to evaluate the new feature.
• Enable the KubeletEnsureSecretPulledImages feature gate in your Kubelet configuration.
• Review your current imagePullPolicy settings and consider switching from Always to IfNotPresent where appropriate to improve performance.
• Ensure that all pods accessing private images correctly reference the necessary imagePullSecrets.
• Monitor Kubelet logs for any authentication failures during the initial rollout to identify misconfigured pods.
• Read KEP-2535 for detailed technical specifications and future roadmap items regarding this feature.