AlwaysPullImages is an admission plugin that rewrites every new pod so its image pull policy is Always. That makes the node check credentials against the registry each time, so a pod from one tenant cannot start from a private image another tenant already pulled to the node. It helps most in multitenant clusters.
The problem it solves
By default an image that is already on a node can be reused. The Kubernetes documentation explains the issue: without this plugin, once an image has been pulled to a node, any pod from any user can use it just by knowing the image name, assuming the pod is scheduled to that node. Private image content then depends on scheduling luck, not on who holds registry credentials.
The documentation calls the plugin both mutating and validating. With it on, every new pod gets image pull policy Always, and the kubelet asks the runtime to pull on every container start. The pull then requires valid credentials, even if the layers are cached.
How pull policy behaves otherwise
The images documentation describes the values. IfNotPresent pulls only if the image is not present locally. Always makes the kubelet ask the container runtime to resolve the digest on every container launch. If a default is not set, the policy depends on the tag and how the image is referenced. Check the page for your version rather than relying on memory.
When it fits and when it does not
| Situation | Fit |
|---|---|
| Shared cluster where teams use separate private registries | Good fit |
| Single team, single registry, no private image secrecy concern | Little benefit |
| Registry with weak availability or strict rate limits | Consider the load first |
| Air gapped or edge sites with intermittent connectivity | Think carefully, pods may fail to start offline |
| Workloads that must restart fast during an incident | Test start times before adopting |
The cost is more registry traffic and a dependency on registry availability at every container start. Pull through caches and mirrors can reduce the strain.
What it does not do
It does not make an image trustworthy. It does not stop someone with credentials from pulling an image. It does not replace network policy, signature verification or scanning. It only closes the cached-image path.
Enabling and checking
The plugin is not in the default list. On a self managed control plane you add it to the enable-admission-plugins flag. On managed services, check whether the provider supports it. Then verify the effect:
- Create a pod without an explicit pull policy.
- Read the created pod and confirm the policy shows Always.
- Test that a pod without access to the registry cannot start from a cached private image.
Rollout notes
Announce the change, watch registry error rates and pod start times, and make sure image pull secrets are present in every namespace that needs them. A kubelet that cannot authenticate will now fail starts that used to succeed from cache. That failure is the feature working, but teams need to know.
Where Safeguard fits
Safeguard's container image scanning shows what a private image contains, which is the other half of the question: controlling who can run an image, and knowing what is in it.
Quick check
Does AlwaysPullImages stop a vulnerable image from running?
No. It only forces credential checks on every pull. Use scanning and policies to judge image content.
Is it a good idea for a single team cluster?
Often little benefit, since the cached image concern is mainly about multiple tenants. Weigh it against extra registry load.
Sources
Last reviewed: 19 October 2026.
