Secure containers across images, registries, runtimes, and hosts

Bottom line: a container image is only one part of the security boundary. The build inputs, registry, orchestrator, runtime configuration, host operating system, network paths, secrets, and monitoring all influence what code runs and what it can reach.

Source fact: what NIST covers

NIST SP 800-190 describes application containers as operating-system virtualization combined with application packaging. NIST explains that containers provide a portable, reusable, and automatable way to package and run applications. The guide addresses potential security concerns and recommendations for container use.

The publication is a technology guide, not a product certification. Its September 2017 date also means teams should pair its enduring architectural guidance with current documentation for the chosen operating system, orchestrator, registry, cloud service, and image tooling.

What the source does not establish

Using containers does not automatically isolate an application to the degree its owner expects. A passed image scan does not establish provenance, safe runtime configuration, host integrity, correct authorization, or absence of a newly disclosed issue. An orchestrator’s default settings and available controls can vary by product and version.

The source does not guarantee that a container can be rebuilt, rolled back, or investigated. Those outcomes require retained inputs, immutable identifiers, logs, and tested operating procedures.

Applicability questions

• Who controls the base images, dependencies, build service, registry, signing or integrity mechanism, and deployment policy?
• Can a mutable tag cause different content to run under the same name?
• Which identities can publish, approve, pull, deploy, exec into, or change a workload?
• What host resources, secrets, networks, storage, devices, or orchestration APIs can the container reach?
• How will the organization find every running instance of a withdrawn image digest?

DSE recommendation: verify the full chain

The following steps are DSE recommendations based on the cited source.

1. Approve base-image sources and record immutable image identifiers. Retain the source revision, dependency set, build identity, build result, and promotion decision.
2. Minimize images and remove unnecessary tools, packages, credentials, and services. Rebuild from maintained inputs rather than making undocumented changes to a running container.
3. Restrict registry publishing, artifact promotion, orchestration administration, secret access, and interactive runtime access. Separate build and production duties where risk justifies it.
4. Set explicit runtime policy for privilege, filesystem writes, host mounts, device access, resource limits, network flows, and service identity. Test that disallowed behavior is actually blocked.
5. Patch and monitor the host and orchestration layers as production infrastructure. Preserve events that connect a running workload to its image digest and deployment change.
6. Rehearse withdrawal: identify every instance, stop or replace it safely, preserve evidence, verify service health, and prevent the artifact from returning through automation.

Verification and evidence

Choose one deployed workload and trace it backward from runtime to image digest, registry record, build, source, dependencies, approvals, and base image. Then test a denied privilege, an image withdrawal, and restoration of the service. Record environment, timestamps, identities, results, and residual exceptions.

Official references

• NIST SP 800-190 — Application Container Security Guide — National Institute of Standards and Technology; finalized September 25, 2017
• NIST Secure Software Development Framework — National Institute of Standards and Technology