Stop 09 · Cloud SecurityTopics · 6/9

Container & Kubernetes Security

In short

Containers package apps to run anywhere, and Kubernetes runs thousands of them. That power needs guarding: a weak image or an over powerful pod can become an attacker's foothold.

Securing containerized workloads — scanning images for vulnerabilities, running containers as non-root, and applying least-privilege roles to Kubernetes workloads specifically.

The blob inspects a sealed shipping container with a checklist at a busy port.

Think of it like this

Shipping containers at a busy port

A port moves goods in sealed containers. Before loading, each is inspected and its paperwork checked, and no single container gets keys to the whole yard. Securing Kubernetes is that port discipline: inspect every image and limit what each container can do.

Watch it happen

Securing the container path

Scan image

Non root

Least priv

Isolate

1/4Scan each image for known vulnerable packages before it ever runs.

The big ideas

What you need to know

Scan images

Base images carry old libraries with known holes. Scan every image in your pipeline and rebuild often.

Never run as root

A root container that escapes can own the host. Run as an unprivileged user and drop extra capabilities.

Tight RBAC

Kubernetes roles decide what each service account can do. Grant the minimum, never cluster admin by default.

Network policies

By default pods can talk freely. Policies restrict traffic, so one compromised pod cannot reach everything.

See it in code

Walk through the code

yaml

1# A hardened pod security context2apiVersion: v13kind: Pod4metadata: { name: web }5spec:6  securityContext:7    runAsNonRoot: true8    runAsUser: 10009  containers:10    - name: web11      image: web:1.4.212      securityContext:13        allowPrivilegeEscalation: false14        readOnlyRootFilesystem: true

1/3runAsNonRoot and a fixed user id stop the container running with root powers.

A safer default pod: it runs as a normal user, cannot gain new privileges, and its root filesystem is read only.

Save yourself the pain

Common mistakes

Oops

Running containers as root because it just works.

Do this instead

A root container that breaks out can take the host. Run as a non root user and drop unneeded capabilities.

Oops

Deploying images without scanning them.

Do this instead

Old base images hide known vulnerabilities. Scan in the pipeline and rebuild on fresh, patched bases.

Your mission

Scan and harden an image

~45 min

Quick check

Why is running a container as a non root user safer?

Go deeper

1Scan a container image using a free tool (like Trivy) and review the vulnerability report.
2Learn why running a container as root unnecessarily expands the blast radius of a compromise.
3Understand basic Kubernetes RBAC as the mechanism for controlling who can do what in a cluster.