Container and Kubernetes Security: The Basics

A container is not a security boundary. Worth establishing up front, because many decisions rest on the opposite assumption: container isolation is materially weaker than a virtual machine's, and container escape is a real risk.

This list focuses on what covers the most common mistakes.

1. Images: smaller is better

A base image containing a full distribution brings hundreds of packages with their own vulnerabilities, none of which the application needs.

• Use a minimal base image (distroless or similar)
• Pin versions by digest rather than the latest tag
• Use multi-stage builds so build tooling never reaches the production image
• Scan images during build and regularly afterwards, because new vulnerabilities appear later

We covered this in detail in our software dependencies article.

2. Do not run as root

By default the process in a container is root. If an escape vulnerability exists, it becomes root on the host too.

• runAsNonRoot: true with a specific user
• Read-only root filesystem where the application permits
• Drop all Linux capabilities and add back only what is needed
• allowPrivilegeEscalation: false

Four lines of configuration covering most of the escape risk.

3. Network policies

By default in Kubernetes every pod reaches every pod. This is the same flat network problem as in traditional infrastructure, at smaller scale.

Deny by default, then permit at namespace and application level. Restricting egress matters too, because it impedes command-and-control channels.

4. Secrets management

A secret baked into the container or passed via environment variables is visible in several places: image layers, the process list, logs.

The answer is an external secrets manager the container reads at runtime. Kubernetes' built-in secret object is only base64-encoded rather than encrypted by default, so encryption at rest must be enabled separately.

5. Protecting the control plane

The Kubernetes API is the most valuable target: every resource is reachable from it.

• The API server should never be publicly reachable
• Role-based access control genuinely narrowed, not cluster-admin for everyone
• Audit logging enabled and shipped to external collection
• kubeconfig files handled as strictly as any admin credential

6. Admission policies

The admission controller is the last gate between build and runtime: here you can prevent privileged containers, unsigned images or pods without resource limits from starting.

First in audit mode to see what would fail, and only then blocking.

What gets forgotten

Host hardening. Containers use the host kernel. If that is not in order, neither is the container. Our Linux hardening article applies here too.

Resource limits. Without limits a runaway container takes down the whole node. This is an availability and a security question.

Logging. Containers are short-lived; logs must outlive them. Without central collection there is nothing to investigate after an incident.

Our IT security services include reviewing the security of containerised environments.