Container Security: Protecting Dockerised and Kubernetes Environments
Containers move the security problem rather than removing it. Image provenance, runtime isolation, secrets, and the Kubernetes defaults that are not safe.
GuardsArm Team
Security Experts
Containers are often described as isolation. They are not, in the sense people usually mean — a container shares the host kernel, and a kernel vulnerability or a misconfigured privilege is an escape. What containers genuinely provide is a reproducible unit of deployment, and that property is what makes them easier to secure than long-lived servers, provided you use it.
The supply chain is the first problem
Most container risk arrives in the image, long before runtime.
- Base image provenance. A
FROMline pointing at an unpinned public tag means your build output changes without your knowledge. Pin by digest, not by tag, and prefer minimal or distroless bases — fewer packages, fewer CVEs, smaller attack surface. - Scan at build and at rest. Scanning in CI catches what you ship; scanning the registry catches images that became vulnerable after they were built, which is most of them.
- Sign and verify. Image signing with admission-time verification is what stops an unreviewed image reaching production.
- Generate an SBOM. When the next widely-exploited library lands, the question "are we affected" should take minutes, not days.
Runtime configuration that matters
A short list does most of the work:
| Control | Why |
|---|---|
| Run as non-root | A root container that escapes is root on the host |
| Read-only root filesystem | Prevents most in-place tampering |
| Drop all capabilities, add back what is needed | Defaults grant more than any application requires |
| No privileged containers | A privileged container is effectively the host |
| Do not mount the Docker socket | Socket access equals cluster control |
| Set resource limits | Prevents one workload starving the node |
| seccomp and AppArmor profiles | Restricts the syscalls available for an escape |
Kubernetes defaults are not safe
Secrets deserve specific mention. Kubernetes Secrets are base64-encoded, not encrypted, in etcd by default. Enable encryption at rest, or use an external secret manager and inject at runtime. Never bake secrets into images — they persist in every layer and in the registry regardless of what the running container shows.
Runtime detection
Build-time scanning says nothing about what a container does once running. Worth detecting:
- A process starting that is not in the image's expected set
- Outbound connections to destinations the workload has never used
- Writes to the filesystem where the root filesystem should be read-only
- Attempts to mount host paths or access the container runtime socket
- A shell spawning inside a production container
That last one is a strong signal in most environments, because there is rarely a legitimate reason for an interactive shell in a running production pod.
For healthcare specifically
Containerised workloads processing PHI inherit the same obligations as anything else: encryption in transit between services, audit logging of access, and a BAA covering the managed Kubernetes service if it is cloud-hosted. Two things that catch teams out:
- Ephemeral does not mean unlogged. A pod that lives ten minutes still needs its access to PHI recorded, and its logs shipped before it disappears.
- Non-production clusters built from production data are a common PHI exposure — see preventing cloud misconfiguration.
GuardsArm assesses container and Kubernetes deployments including image supply chain and cluster configuration review. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on this topic
Talk to the GuardsArm team about how these services apply to your environment.
