Include init containers in a Kubernetes image-name inventory

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.

Source fact: documented behavior

The List All Container Images Running in a Cluster documentation is the primary reference.

The 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.

What the source does not establish

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.

Applicability questions

• Which namespaces and label selection define the intended population?
• Must the record include both initialization and application images?
• Is the requested evidence an image name, a runtime identity or assessment coverage?
• Who will explain omissions when an inventory query changes?

DSE recommendation: preserve the query population

DSE 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.

For 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.

Separate 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.

Verification and evidence

Proposed 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.

Repeat 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.

Official references

• List All Container Images Running in a Cluster — Kubernetes.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.