Bottom line: Define what an image inventory includes before counting its output. Preserve the container fields and Pod population in the collection record so a shorter query does not silently become a narrower security or maintenance inventory.
\nThe List All Container Images Running in a Cluster documentation is the primary reference.
\nThe all-namespace example extracts image names from both initContainers and containers under each Pod specification. The label-filtered and namespace-filtered examples shown on the page select spec.containers image fields.
This article concerns the documented image-name query, not proof of immutable runtime identity, successful vulnerability assessment or application use. It does not inventory a deleted workload or a registry by implication. Agree those wider requirements separately instead of calling every list a complete running-software inventory.
\nDSE recommends storing the collection definition beside the resulting list. Name the cluster context, namespace scope, label selection and selected Pod fields. Keep a readable explanation of the JSONPath so another operator can distinguish an intentional exclusion from an accidental query edit.
\nFor an inventory that requires initialization images, start from the tutorial’s all-namespace selection of both container arrays. Review the --all-namespaces scope and the fields before adapting it. If the owner asks for a namespace or label filter, retain that requirement while checking the container-array selection independently. Do not accept a pasted example solely because its output looks plausible.
Keep an attributable view before producing a summary. Record which Pod and namespace contributed each image name, then make the aggregated count a separate presentation. This gives the reviewer a way to investigate a missing entry without guessing which workload supplied it. Protect operational names according to the organization’s handling rules.
\nSeparate collection from the next decision. Give image withdrawal, runtime-digest reconciliation and vulnerability-assessment eligibility their own evidence requirements. A recipient should be able to tell which question this particular inventory answers and which supporting record is still needed.
\nProposed verification, not performed: use a disposable Pod with different harmless image names in its initialization and application definitions. Write the expected two-array population before running the documented collection. Compare that result with a deliberately application-only selection, identifying the narrower query as a test input.
\nRepeat with an agreed namespace and label selection. Reconcile expected membership before interpreting counts, and preserve the exact invocation, context and time. Ask a second operator to trace each expected name back to the relevant Pod field. Record any unavailable namespace or collection error as a coverage gap rather than reporting an unqualified complete inventory.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Define what an image inventory includes before counting its output. Preserve the container fields and Pod population in the collection record so a shorter query does not silently become a narrower security or maintenance inventory.\nSource fact: documented behavior\nThe List All Container Images Running in a Cluster documentation is the primary reference.\nThe all-namespace example extracts image names from both initContainers and containers under each Pod specification. The label-filtered and namespace-filtered examples shown on the page select spec.containers image fields.\nWhat the source does not establish\nThis article concerns the documented image-name query, not proof of immutable runtime identity, successful vulnerability assessment or application use. It does not inventory a deleted workload or a registry by implication. Agree those wider requirements separately instead of calling every list a complete running-software inventory.\nApplicability questions\n\nWhich namespaces and label selection define the intended population?\nMust the record include both initialization and application images?\nIs the requested evidence an image name, a runtime identity or assessment coverage?\nWho will explain omissions when an inventory query changes?\n\nDSE recommendation: preserve the query population\nDSE recommends storing the collection definition beside the resulting list. Name the cluster context, namespace scope, label selection and selected Pod fields. Keep a readable explanation of the JSONPath so another operator can distinguish an intentional exclusion from an accidental query edit.\nFor an inventory that requires initialization images, start from the tutorial’s all-namespace selection of both container arrays. Review the --all-namespaces scope and the fields before adapting it. If the owner asks for a namespace or label filter, retain that requirement while checking the container-array selection independently. Do not accept a pasted example solely because its output looks plausible.\nKeep an attributable view before producing a summary. Record which Pod and namespace contributed each image name, then make the aggregated count a separate presentation. This gives the reviewer a way to investigate a missing entry without guessing which workload supplied it. Protect operational names according to the organization’s handling rules.\nSeparate collection from the next decision. Give image withdrawal, runtime-digest reconciliation and vulnerability-assessment eligibility their own evidence requirements. A recipient should be able to tell which question this particular inventory answers and which supporting record is still needed.\nVerification and evidence\nProposed verification, not performed: use a disposable Pod with different harmless image names in its initialization and application definitions. Write the expected two-array population before running the documented collection. Compare that result with a deliberately application-only selection, identifying the narrower query as a test input.\nRepeat with an agreed namespace and label selection. Reconcile expected membership before interpreting counts, and preserve the exact invocation, context and time. Ask a second operator to trace each expected name back to the relevant Pod field. Record any unavailable namespace or collection error as a coverage gap rather than reporting an unqualified complete inventory.\nOfficial references\n\nList All Container Images Running in a Cluster — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Define what an image inventory includes before counting its output. Preserve the container fields and Pod population in the collection record so a shorter query does not silently become a narrower security or maintenance inventory.\n\n## Source fact: documented behavior\n\nThe [List All Container Images Running in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/) documentation is the primary reference.\n\nThe all-namespace example extracts image names from both initContainers and containers under each Pod specification. The label-filtered and namespace-filtered examples shown on the page select spec.containers image fields.\n\n## What the source does not establish\n\nThis article concerns the documented image-name query, not proof of immutable runtime identity, successful vulnerability assessment or application use. It does not inventory a deleted workload or a registry by implication. Agree those wider requirements separately instead of calling every list a complete running-software inventory.\n\n## Applicability questions\n\n- Which namespaces and label selection define the intended population?\n\n- Must the record include both initialization and application images?\n\n- Is the requested evidence an image name, a runtime identity or assessment coverage?\n\n- Who will explain omissions when an inventory query changes?\n\n## DSE recommendation: preserve the query population\n\nDSE recommends storing the collection definition beside the resulting list. Name the cluster context, namespace scope, label selection and selected Pod fields. Keep a readable explanation of the JSONPath so another operator can distinguish an intentional exclusion from an accidental query edit.\n\nFor an inventory that requires initialization images, start from the tutorial’s all-namespace selection of both container arrays. Review the --all-namespaces scope and the fields before adapting it. If the owner asks for a namespace or label filter, retain that requirement while checking the container-array selection independently. Do not accept a pasted example solely because its output looks plausible.\n\nKeep an attributable view before producing a summary. Record which Pod and namespace contributed each image name, then make the aggregated count a separate presentation. This gives the reviewer a way to investigate a missing entry without guessing which workload supplied it. Protect operational names according to the organization’s handling rules.\n\nSeparate collection from the next decision. Give image withdrawal, runtime-digest reconciliation and vulnerability-assessment eligibility their own evidence requirements. A recipient should be able to tell which question this particular inventory answers and which supporting record is still needed.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable Pod with different harmless image names in its initialization and application definitions. Write the expected two-array population before running the documented collection. Compare that result with a deliberately application-only selection, identifying the narrower query as a test input.\n\nRepeat with an agreed namespace and label selection. Reconcile expected membership before interpreting counts, and preserve the exact invocation, context and time. Ask a second operator to trace each expected name back to the relevant Pod field. Record any unavailable namespace or collection error as a coverage gap rather than reporting an unqualified complete inventory.\n\n## Official references\n\n- [List All Container Images Running in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/) — Kubernetes.\n\nSource review completed October 28, 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/include-init-containers-in-a-kubernetes-image-name-inventory/", "url": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Include init containers in a Kubernetes image-name inventory", "item": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/#article", "identifier": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/", "url": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/", "headline": "Include init containers in a Kubernetes image-name inventory", "description": "The documented all-namespace query includes init and application container image fields. Keep that population explicit when filtering or changing the query.", "abstract": "The documented all-namespace query includes init and application container image fields. Keep that population explicit when filtering or changing the query.", "articleBody": "Bottom line: Define what an image inventory includes before counting its output. Preserve the container fields and Pod population in the collection record so a shorter query does not silently become a narrower security or maintenance inventory.\nSource fact: documented behavior\nThe List All Container Images Running in a Cluster documentation is the primary reference.\nThe all-namespace example extracts image names from both initContainers and containers under each Pod specification. The label-filtered and namespace-filtered examples shown on the page select spec.containers image fields.\nWhat the source does not establish\nThis article concerns the documented image-name query, not proof of immutable runtime identity, successful vulnerability assessment or application use. It does not inventory a deleted workload or a registry by implication. Agree those wider requirements separately instead of calling every list a complete running-software inventory.\nApplicability questions\n\nWhich namespaces and label selection define the intended population?\nMust the record include both initialization and application images?\nIs the requested evidence an image name, a runtime identity or assessment coverage?\nWho will explain omissions when an inventory query changes?\n\nDSE recommendation: preserve the query population\nDSE recommends storing the collection definition beside the resulting list. Name the cluster context, namespace scope, label selection and selected Pod fields. Keep a readable explanation of the JSONPath so another operator can distinguish an intentional exclusion from an accidental query edit.\nFor an inventory that requires initialization images, start from the tutorial’s all-namespace selection of both container arrays. Review the --all-namespaces scope and the fields before adapting it. If the owner asks for a namespace or label filter, retain that requirement while checking the container-array selection independently. Do not accept a pasted example solely because its output looks plausible.\nKeep an attributable view before producing a summary. Record which Pod and namespace contributed each image name, then make the aggregated count a separate presentation. This gives the reviewer a way to investigate a missing entry without guessing which workload supplied it. Protect operational names according to the organization’s handling rules.\nSeparate collection from the next decision. Give image withdrawal, runtime-digest reconciliation and vulnerability-assessment eligibility their own evidence requirements. A recipient should be able to tell which question this particular inventory answers and which supporting record is still needed.\nVerification and evidence\nProposed verification, not performed: use a disposable Pod with different harmless image names in its initialization and application definitions. Write the expected two-array population before running the documented collection. Compare that result with a deliberately application-only selection, identifying the narrower query as a test input.\nRepeat with an agreed namespace and label selection. Reconcile expected membership before interpreting counts, and preserve the exact invocation, context and time. Ask a second operator to trace each expected name back to the relevant Pod field. Record any unavailable namespace or collection error as a coverage gap rather than reporting an unqualified complete inventory.\nOfficial references\n\nList All Container Images Running in a Cluster — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:09:55+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/" }, "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/include-init-containers-in-a-kubernetes-image-name-inventory/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Include init containers in a Kubernetes image-name inventory" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 501, "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 — List All Container Images Running in a Cluster", "url": "https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/" } } ] } }