What Is Container Security?

What is container security?

Container security is the practice of protecting containerized applications and what they run on across their whole life: the image you build, the registry that stores it, the orchestrator that deploys it, the running container and the host underneath. Containers share the host kernel and are rebuilt often, so image contents and configuration matter more than hardening a long-lived server. NIST covers the topic in SP 800-190, the Application Container Security Guide.

The five layers

1. Images (build time)

• Start from a minimal base image so there are fewer packages to patch.
• Pin versions, ideally by digest, instead of using latest.
• Scan images for known vulnerabilities in CI and fail the build above a severity you choose.
• Run as a non-root user and keep secrets out of the image.
• Sign images and verify the signature before deploy.

2. Registry

• Use a private registry with access control and audit logs.
• Re-scan stored images, since new vulnerabilities are published after a push.

3. Orchestrator (Kubernetes)

• Least-privilege RBAC and a separate service account per workload.
• NetworkPolicies that deny traffic by default, then allow what each pod needs.
• Enforce the Kubernetes Pod Security Standards (Privileged, Baseline, Restricted) and prefer Restricted for application workloads.
• Admission controllers to reject non-compliant manifests, and API server audit logging.
• Secrets from the Secret API with encryption at rest, or an external secrets manager.

4. Runtime

• Drop Linux capabilities you do not need, use a read-only root filesystem where the app allows it, and avoid privileged containers.
• Apply seccomp and AppArmor or SELinux profiles to limit system calls.
• Watch for odd behavior such as a shell starting in a production container or unexpected outbound connections.

5. Host

• Patch the kernel and the container runtime. A shared kernel means a kernel flaw affects every container on the node.
• Use a minimal, container-focused host OS and restrict direct logins.

Example

A team ships a Node service on a full OS base image, as root, tagged latest, with a database password in an environment variable. Moving to a slim image pinned by digest, a non-root user, a read-only filesystem, a Secret mounted at run time and a default-deny NetworkPolicy removes most of the ways a flaw in one dependency can become access to the database or the node.

Common mistakes

• Running as root because the image default allows it.
• Pulling latest in production, so a rebuild changes what you run without a review.
• Privileged containers "to make it work", which removes most isolation.
• Scanning only at build time and never re-scanning what is already deployed.
• Leaving all pod-to-pod and outbound traffic open, so one compromised pod can reach everything.
• Sharing one broad service account between workloads.
• Configuring clusters by hand. Keep manifests in version control and review them like code; see infrastructure as code.

Related concepts

Splitting an application into microservices multiplies the number of images and network paths to secure. Workload and human access should follow identity and access management principles, and the wider picture of what attackers try is in cyber security threats.

Where LoadFocus fits

LoadFocus is not a container security product: it does not scan images, check cluster configuration or detect intrusions. It helps with the performance side of a hardened setup. Sidecars, mTLS, policy engines and runtime agents add latency and CPU cost, and a load test shows whether the service still meets its response-time target at expected traffic. API monitoring then watches endpoint availability and speed after each deploy. For security testing practice in the cloud, see cloud testing security best practices.

FAQ: container security

Are containers less secure than virtual machines?

They isolate differently. Containers share the host kernel, so a kernel flaw or a privileged container can affect the whole node, while a virtual machine has its own kernel. Containers are smaller and easier to rebuild and scan. Either can be secure or insecure depending on configuration.

What is the first thing to fix?

Run as non-root, stop using latest, and scan images in CI. They are cheap and remove the most common problems.

Do I need runtime security tooling?

Build-time scanning only finds known vulnerabilities. Runtime detection catches behavior that scanning cannot, such as an unexpected shell or outbound connection. It matters most for sensitive production clusters.

What do the Kubernetes Pod Security Standards do?

They define three policy levels: Privileged (unrestricted), Baseline (blocks known privilege escalations) and Restricted (follows current pod hardening practice). You enforce one per namespace.

Does serverless container hosting remove the problem?

It moves host and orchestrator security to the provider. Image contents, secrets, permissions and network rules remain your responsibility.