How do you Secure a Container?

You secure a container by applying layered controls across the five components of the container stack: the image, the registry, the orchestrator, the running container, and the host operating system. NIST Special Publication 800-190, the Application Container Security Guide, defines this layered model and its countermeasures.

To secure a container, scan images for vulnerabilities before deployment, pull only from trusted private registries, sign images so their origin can be verified, run containers as non-root with least privilege, harden the orchestrator and host operating system, keep secrets out of images, and monitor runtime behavior continuously. NIST SP 800-190 defines these countermeasures.

Key Takeaways

• Container security spans five layers defined in NIST SP 800-190: image, registry, orchestrator, container runtime, and host operating system.
• Minimal base images, non-root execution, and image signing remove the most common container attack paths before deployment.
• Kubernetes removed PodSecurityPolicy in version 1.25; Pod Security Admission now enforces the Privileged, Baseline, and Restricted standards through namespace labels.
• Docker began retiring Docker Content Trust in August 2025; Sigstore Cosign and Notary Project Notation are the current standards for signing container images.
• Every container platform runs on keys, certificates, and secrets. Signing keys belong in an HSM, and credentials belong in a secrets manager, never in the image.

What Is a Container?

A container is a standalone software unit that packages application code together with its dependencies so the application runs consistently across computing environments.

Containers are a form of operating system virtualization. A container holds the executables, binaries, libraries, and configuration files an application needs, but not a full operating system image, which keeps containers lightweight and portable. A single container can run anything from a small microservice to a larger application.

Containers are created from container images. An image is built as layers of files, with a base image at the bottom and application layers above it. Because every derived image inherits the base layer, the base image is the most critical layer to secure.

What Is Container Management?

Container management is the automation of container creation, deployment, and scaling across an environment.

Container management platforms let teams add, replace, and organize containers at scale. In practice, that means analyzing and controlling the images teams download and build, hosting them in private registries, applying role-based access, automating policy, and surfacing vulnerabilities before images reach production. Automation reduces the human error that manual container operations invite.

Why Does Container Security Matter?

Container security matters because containers now run a large share of production workloads, and a single vulnerable container can become an entry point into the wider infrastructure.

Containers provide real isolation benefits, but they also expand the attack surface. Containers on the same host share the host kernel, so a container escape threatens every workload on that machine. Most container traffic is east-west traffic between services inside the cluster, which perimeter tools such as web application firewalls and intrusion prevention systems were never designed to inspect. Purpose-built controls have to fill that gap.

How Do You Secure a Container? The NIST SP 800-190 Model

The Application Container Security Guide, published by NIST as Special Publication 800-190 in September 2017, organizes container security around five components: images, registries, orchestrators, containers, and the host operating system. Securing a container means applying controls at each layer.

Layer	Primary risks	Core controls
Image	Known vulnerabilities, embedded secrets, untrusted sources	Scan in CI and in the registry, use minimal base images, sign with Cosign or Notation
Registry	Stale images, insecure access	Private registry, strong authentication, prune old images, scan on push
Orchestrator	Unbounded admin access, unprotected pod-to-pod traffic	RBAC least privilege, Pod Security Admission, network policies
Container	Runtime attacks, privilege escalation, image drift	Non-root users, dropped capabilities, runtime threat detection
Host OS	Large attack surface, shared kernel	Container-specific host OS, prompt patching, restricted access

Three NIST recommendations deserve emphasis. First, run containers on a container-specific host operating system, which ships with fewer features and a smaller attack surface than a general-purpose OS. Second, group containers by purpose, sensitivity, and risk profile on separate hosts, so compromising one group does not hand an attacker the others. Third, use container-aware vulnerability management and runtime security tools. Traditional scanners have blind spots around image layers and configuration, and they can report that everything is fine when it is not.

Docker Container Security Best Practices

The highest impact Docker controls are minimal trusted images, least privilege at runtime, and signed artifacts.

1. Use minimal, trusted base images: Pull only from credible sources such as Docker Official Images and verified publishers, and prefer slim or distroless variants. Fewer packages mean fewer vulnerabilities to inherit.
2. Run as non-root with least privilege: Set a non-root user in the Dockerfile, drop Linux capabilities the application does not need, and avoid privileged mode.
3. Keep secrets out of images: Never bake passwords, tokens, or keys into a Dockerfile or image layer. Inject credentials at runtime from a secrets manager.
4. Sign and verify images: Use Sigstore Cosign or Notary Project Notation. Docker began retiring Docker Content Trust on August 8, 2025, and the Notary v1 service behind it shuts down on December 8, 2026, so do not build new verification on DCT.
5. Scan continuously and rebuild rather than patch: Scan images in the pipeline and in the registry, and treat containers as short-lived and immutable. When a fix lands, rebuild and redeploy the image.
6. Do not run SSH inside containers: Troubleshoot through docker exec or the orchestrator instead of shipping a login daemon in every workload.

Kubernetes Container Security Best Practices

Kubernetes security starts with a supported version and namespace-level policy enforcement.

• Stay on a supported release: Kubernetes ships three minor releases a year, and each receives patches for roughly 14 months. Running an unsupported version means running without security fixes.
• Enforce Pod Security Standards: PodSecurityPolicy was deprecated in v1.21 and removed in v1.25. Apply the Baseline or Restricted standard through Pod Security Admission namespace labels, and add a policy engine such as OPA Gatekeeper or Kyverno where you need custom rules.
• Lock down access: Apply least-privilege RBAC to the API server and restrict SSH access to nodes. Port 22 should be closed on every node except through your VPN or a bastion path.
• Use namespaces and network policies as boundaries: Separate workloads into namespaces and apply NetworkPolicy objects so pods can only talk to the services they need.
• Protect Secrets: Enable encryption at rest for Kubernetes Secrets and prefer an external secrets store for high-value credentials.
• Audit and monitor: Enable audit logs and alert on authorization failures, which often indicate stolen credentials being tried against the API.

AWS Container Security Best Practices

On AWS, container security centers on Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), and image scanning in Amazon Elastic Container Registry (ECR).

• Scan in ECR: Enable scan on push. Basic scanning uses AWS native technology to find operating system package vulnerabilities. Enhanced scanning, an integration with Amazon Inspector, adds programming language packages, continuous rescanning as new CVEs publish, and since 2025 covers minimal bases such as scratch, distroless, and Chainguard images. Inspector also maps images to the ECS and EKS workloads running them, which helps you fix what is actually deployed first.
• Respect the shared responsibility model: AWS secures the underlying infrastructure; you secure your images, task and pod configuration, IAM permissions, and network access. Tools such as Prowler help verify the environment before deployment.
• Remove unnecessary privileges: Grant tasks and pods scoped IAM roles instead of broad node-level permissions. The more default access a container has, the larger the blast radius and the harder the forensics after a breach.
• Look beyond the container: Assess the hosts and control plane too, scan regularly, and keep every component patched.

Microsoft Azure Container Security Best Practices

On Azure, container security centers on Azure Container Registry (ACR) and Microsoft Defender for Containers.

• Use a private registry: Store and pull images from ACR rather than public repositories, since public images are built from many software layers and any layer can carry a vulnerability. Note that ACR is deprecating Docker Content Trust (deprecation began March 31, 2025, removal on March 31, 2028) in favor of Notary Project signing with Notation.
• Scan with Defender for Containers: Microsoft Defender for Cloud, the service formerly named Azure Security Center until its November 2021 rename, performs agentless vulnerability assessment of ACR images through Microsoft Defender Vulnerability Management. The earlier integrated Qualys container scanner was retired in March 2024.
• Secure credentials: Containers spread across regions and clusters, so keep passwords, tokens, and API keys in Azure Key Vault and use managed identities for service-to-service authentication instead of embedded secrets.

Where Cryptography Fits in Container Security

Every layer of a container platform depends on keys, certificates, and secrets.

Image signatures are only as strong as the private keys behind them, so signing keys belong in a hardware security module or a managed KMS, not on a build server. TLS certificates protect traffic between registries, API servers, and workloads, and service meshes push that further with mutual TLS between pods, which requires certificate issuance and rotation at machine speed from your public key infrastructure (PKI). Pipeline and workload identities follow the same rule as the DevOps toolchain they run in: short-lived credentials, issued centrally, revocable instantly. A container platform is only as trustworthy as the keys, certificates, and secrets that run it.

How Encryption Consulting Helps

Encryption Consulting’s Securing DevOps solutions protect the cryptographic layer every container pipeline depends on. CodeSign Secure centralizes code and artifact signing behind FIPS 140-2 Level 3 validated HSMs and integrates with CI/CD tools including Jenkins, GitLab, and Azure DevOps, so every image and artifact is signed, timestamped, and logged without slowing delivery. Advisory teams then help you manage the certificates, keys, and secrets your clusters run on. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is container security in simple terms?

Container security is the practice of protecting containerized applications at every layer: the image the container is built from, the registry that stores it, the orchestrator that schedules it, the running container itself, and the host operating system underneath. NIST SP 800-190 defines the risks and countermeasures for each of these five layers.

How do you secure a Docker container?

Start with a minimal, trusted base image and rebuild it regularly instead of patching running containers. Run the container as a non-root user, drop unneeded Linux capabilities, and never bake credentials into the image. Scan images in the pipeline and the registry, and sign them with Sigstore Cosign or Notation so only verified images reach production.

What is NIST SP 800-190?

NIST Special Publication 800-190 is the Application Container Security Guide, published by the US National Institute of Standards and Technology in September 2017. It describes the security risks of container technologies across images, registries, orchestrators, containers, and host operating systems, and recommends countermeasures for each. It remains the baseline reference for container security programs and audits.

What replaced Pod Security Policies in Kubernetes?

Pod Security Admission replaced PodSecurityPolicy, which was deprecated in Kubernetes 1.21 and removed in 1.25. Pod Security Admission enforces the three Pod Security Standards, Privileged, Baseline, and Restricted, through namespace labels. Teams that need finer-grained rules than the built-in standards typically add a policy engine such as OPA Gatekeeper or Kyverno on top.

Should container images be signed?

Yes. Signing lets your cluster verify that an image came from a trusted publisher and was not modified after it was built. Docker Content Trust, the older signing mechanism, began retiring in August 2025 and its Notary v1 service shuts down in December 2026, so new pipelines should use Sigstore Cosign or Notary Project Notation, and admission controls should block unsigned images from reaching production.

Secure Your Container Pipeline

Signed images, protected keys, and hardened clusters keep a fast container platform trustworthy. Explore Securing DevOps, see CodeSign Secure in action, or talk to an Encryption Consulting advisor.