Bottom line: Make the desired image pull behavior explicit in the update review. Compare the existing stored policy with the proposed image reference before accepting a tag change as the complete deployment change.
\nThe Images documentation is the primary reference.
\nWhen imagePullPolicy is omitted, Kubernetes defaults a digest or a non-latest tag to IfNotPresent, and defaults a latest tag or an omitted tag to Always. That default is set when the object is first created; a later image tag or digest change does not automatically revise the stored policy. With Always, the runtime resolves the image through the registry and downloads uncached layers, but it can reuse layers already present locally.
This article reviews creation-time defaulting and explicit update intent. It does not approve mutable production tags, promise offline startup or replace registry authorization and credential verification. It excludes the separate runtime-class and image-credential-verification extensions described on the page.
\nDSE recommends a before-and-after record containing the container identity, image reference and effective pull policy. Retrieve the existing managed definition through the approved cluster workflow. Keep the proposed source manifest beside the stored object, rather than treating an omitted field as an instruction whose meaning is obvious.
\nAsk the release owner to state the desired behavior for the update. If the requirement calls for a specific policy, include that field in the reviewed change. Do not introduce a latest tag merely as a convenient way to express a pull requirement. Keep image-content identity and pull behavior as two separately accepted choices.
\nReview the entire controller-managed path used by the application. Identify where the Pod template is maintained and which automation submits it. Compare the resulting container settings after the normal deployment process. Preserve a difference between the submitted configuration and the stored result as evidence for the controller or admission owner to investigate.
\nKeep cache observations precise. Record the image digest and relevant pull events using approved tools, while leaving reusable credentials outside the evidence. Do not count downloaded bytes as the sole proof of the intended policy. Require the application’s normal release checks separately before accepting the updated workload.
\nProposed verification, not performed: use a disposable workload with an approved test image and a non-latest tag, initially omitting imagePullPolicy. Inspect and retain the actual stored value. Prepare a reviewed image-reference change and write the expected policy before submitting it.
\nCompare that stored result with a separate fixture that explicitly specifies the intended policy. If examining warm-cache behavior is authorized, preserve the cache condition, actual digest, registry access observations and container settings for each case. Keep the test narrowly focused on defaulting and explicit update intent; do not report a complete authorization or offline-recovery result from a successful container start.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Make the desired image pull behavior explicit in the update review. Compare the existing stored policy with the proposed image reference before accepting a tag change as the complete deployment change.\nSource fact: documented behavior\nThe Images documentation is the primary reference.\nWhen imagePullPolicy is omitted, Kubernetes defaults a digest or a non-latest tag to IfNotPresent, and defaults a latest tag or an omitted tag to Always. That default is set when the object is first created; a later image tag or digest change does not automatically revise the stored policy. With Always, the runtime resolves the image through the registry and downloads uncached layers, but it can reuse layers already present locally.\nWhat the source does not establish\nThis article reviews creation-time defaulting and explicit update intent. It does not approve mutable production tags, promise offline startup or replace registry authorization and credential verification. It excludes the separate runtime-class and image-credential-verification extensions described on the page.\nApplicability questions\n\nWas the stored pull policy explicit or defaulted when this object was created?\nWhich tag or digest is proposed now?\nWhat pull behavior does the release owner actually require?\nWhich effective object and runtime observations will demonstrate that requirement?\n\nDSE recommendation: review the stored policy with the image change\nDSE recommends a before-and-after record containing the container identity, image reference and effective pull policy. Retrieve the existing managed definition through the approved cluster workflow. Keep the proposed source manifest beside the stored object, rather than treating an omitted field as an instruction whose meaning is obvious.\nAsk the release owner to state the desired behavior for the update. If the requirement calls for a specific policy, include that field in the reviewed change. Do not introduce a latest tag merely as a convenient way to express a pull requirement. Keep image-content identity and pull behavior as two separately accepted choices.\nReview the entire controller-managed path used by the application. Identify where the Pod template is maintained and which automation submits it. Compare the resulting container settings after the normal deployment process. Preserve a difference between the submitted configuration and the stored result as evidence for the controller or admission owner to investigate.\nKeep cache observations precise. Record the image digest and relevant pull events using approved tools, while leaving reusable credentials outside the evidence. Do not count downloaded bytes as the sole proof of the intended policy. Require the application’s normal release checks separately before accepting the updated workload.\nVerification and evidence\nProposed verification, not performed: use a disposable workload with an approved test image and a non-latest tag, initially omitting imagePullPolicy. Inspect and retain the actual stored value. Prepare a reviewed image-reference change and write the expected policy before submitting it.\nCompare that stored result with a separate fixture that explicitly specifies the intended policy. If examining warm-cache behavior is authorized, preserve the cache condition, actual digest, registry access observations and container settings for each case. Keep the test narrowly focused on defaulting and explicit update intent; do not report a complete authorization or offline-recovery result from a successful container start.\nOfficial references\n\nImages — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Make the desired image pull behavior explicit in the update review. Compare the existing stored policy with the proposed image reference before accepting a tag change as the complete deployment change.\n\n## Source fact: documented behavior\n\nThe [Images](https://kubernetes.io/docs/concepts/containers/images/) documentation is the primary reference.\n\nWhen imagePullPolicy is omitted, Kubernetes defaults a digest or a non-latest tag to IfNotPresent, and defaults a latest tag or an omitted tag to Always. That default is set when the object is first created; a later image tag or digest change does not automatically revise the stored policy. With Always, the runtime resolves the image through the registry and downloads uncached layers, but it can reuse layers already present locally.\n\n## What the source does not establish\n\nThis article reviews creation-time defaulting and explicit update intent. It does not approve mutable production tags, promise offline startup or replace registry authorization and credential verification. It excludes the separate runtime-class and image-credential-verification extensions described on the page.\n\n## Applicability questions\n\n- Was the stored pull policy explicit or defaulted when this object was created?\n\n- Which tag or digest is proposed now?\n\n- What pull behavior does the release owner actually require?\n\n- Which effective object and runtime observations will demonstrate that requirement?\n\n## DSE recommendation: review the stored policy with the image change\n\nDSE recommends a before-and-after record containing the container identity, image reference and effective pull policy. Retrieve the existing managed definition through the approved cluster workflow. Keep the proposed source manifest beside the stored object, rather than treating an omitted field as an instruction whose meaning is obvious.\n\nAsk the release owner to state the desired behavior for the update. If the requirement calls for a specific policy, include that field in the reviewed change. Do not introduce a latest tag merely as a convenient way to express a pull requirement. Keep image-content identity and pull behavior as two separately accepted choices.\n\nReview the entire controller-managed path used by the application. Identify where the Pod template is maintained and which automation submits it. Compare the resulting container settings after the normal deployment process. Preserve a difference between the submitted configuration and the stored result as evidence for the controller or admission owner to investigate.\n\nKeep cache observations precise. Record the image digest and relevant pull events using approved tools, while leaving reusable credentials outside the evidence. Do not count downloaded bytes as the sole proof of the intended policy. Require the application’s normal release checks separately before accepting the updated workload.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable workload with an approved test image and a non-latest tag, initially omitting imagePullPolicy. Inspect and retain the actual stored value. Prepare a reviewed image-reference change and write the expected policy before submitting it.\n\nCompare that stored result with a separate fixture that explicitly specifies the intended policy. If examining warm-cache behavior is authorized, preserve the cache condition, actual digest, registry access observations and container settings for each case. Keep the test narrowly focused on defaulting and explicit update intent; do not report a complete authorization or offline-recovery result from a successful container start.\n\n## Official references\n\n- [Images](https://kubernetes.io/docs/concepts/containers/images/) — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/", "url": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Review imagePullPolicy explicitly when changing a Kubernetes image reference", "item": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/#article", "identifier": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/", "url": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/", "headline": "Review imagePullPolicy explicitly when changing a Kubernetes image reference", "description": "Check the stored pull policy during an image-tag change instead of assuming Kubernetes recomputes its creation-time default.", "abstract": "Check the stored pull policy during an image-tag change instead of assuming Kubernetes recomputes its creation-time default.", "articleBody": "Bottom line: Make the desired image pull behavior explicit in the update review. Compare the existing stored policy with the proposed image reference before accepting a tag change as the complete deployment change.\nSource fact: documented behavior\nThe Images documentation is the primary reference.\nWhen imagePullPolicy is omitted, Kubernetes defaults a digest or a non-latest tag to IfNotPresent, and defaults a latest tag or an omitted tag to Always. That default is set when the object is first created; a later image tag or digest change does not automatically revise the stored policy. With Always, the runtime resolves the image through the registry and downloads uncached layers, but it can reuse layers already present locally.\nWhat the source does not establish\nThis article reviews creation-time defaulting and explicit update intent. It does not approve mutable production tags, promise offline startup or replace registry authorization and credential verification. It excludes the separate runtime-class and image-credential-verification extensions described on the page.\nApplicability questions\n\nWas the stored pull policy explicit or defaulted when this object was created?\nWhich tag or digest is proposed now?\nWhat pull behavior does the release owner actually require?\nWhich effective object and runtime observations will demonstrate that requirement?\n\nDSE recommendation: review the stored policy with the image change\nDSE recommends a before-and-after record containing the container identity, image reference and effective pull policy. Retrieve the existing managed definition through the approved cluster workflow. Keep the proposed source manifest beside the stored object, rather than treating an omitted field as an instruction whose meaning is obvious.\nAsk the release owner to state the desired behavior for the update. If the requirement calls for a specific policy, include that field in the reviewed change. Do not introduce a latest tag merely as a convenient way to express a pull requirement. Keep image-content identity and pull behavior as two separately accepted choices.\nReview the entire controller-managed path used by the application. Identify where the Pod template is maintained and which automation submits it. Compare the resulting container settings after the normal deployment process. Preserve a difference between the submitted configuration and the stored result as evidence for the controller or admission owner to investigate.\nKeep cache observations precise. Record the image digest and relevant pull events using approved tools, while leaving reusable credentials outside the evidence. Do not count downloaded bytes as the sole proof of the intended policy. Require the application’s normal release checks separately before accepting the updated workload.\nVerification and evidence\nProposed verification, not performed: use a disposable workload with an approved test image and a non-latest tag, initially omitting imagePullPolicy. Inspect and retain the actual stored value. Prepare a reviewed image-reference change and write the expected policy before submitting it.\nCompare that stored result with a separate fixture that explicitly specifies the intended policy. If examining warm-cache behavior is authorized, preserve the cache condition, actual digest, registry access observations and container settings for each case. Keep the test narrowly focused on defaulting and explicit update intent; do not report a complete authorization or offline-recovery result from a successful container start.\nOfficial references\n\nImages — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:30+00:00", "dateModified": "2026-10-30T06:05:14+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review imagePullPolicy explicitly when changing a Kubernetes image reference" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 533, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Images", "url": "https://kubernetes.io/docs/concepts/containers/images/" } } ] } }