Container Security Basics: Docker and Kubernetes Essentials
Container security is the practice of protecting the images you build, the platforms that run them, and the workloads themselves. Start with minimal, scanned images, run containers as non-root with limited capabilities, keep secrets out of images, restrict network traffic, and monitor what happens at runtime.
How containers differ from virtual machines
A virtual machine includes its own operating system kernel. Containers share the host kernel and isolate processes using operating system features. That makes them lightweight and quick to start, but the isolation boundary is thinner: a vulnerability in the kernel or a container running with excess privilege can affect the host and other containers.
Secure the image
- Use minimal base images. Fewer packages mean fewer vulnerabilities and a smaller attack surface.
- Pin versions instead of using floating tags, so builds are repeatable and you know what you are running.
- Pull from trusted registries and verify image provenance, ideally using signing.
- Scan images for known vulnerabilities in the build pipeline and again on a schedule, since new flaws are published after you build.
- Rebuild regularly. Patching a running container is not a durable fix; update the image and redeploy.
- Never bake secrets into images. Anything in a layer can be extracted by whoever receives the image.
Run with least privilege
- Run as a non-root user inside the container.
- Drop unnecessary Linux capabilities and add back only those needed.
- Avoid privileged mode and avoid mounting the container runtime socket, which effectively grants control of the host.
- Use a read-only root filesystem where the application allows, with specific writable volumes.
- Set resource limits for CPU and memory to contain runaway or abusive workloads.
- Apply default security profiles such as seccomp to restrict system calls.
Kubernetes-specific basics
Control access to the cluster
Use role-based access control with least privilege, and avoid giving users or services cluster-admin rights. Protect the API server from public exposure and require strong authentication.
Network policies
By default, pods in a cluster can usually talk to each other freely. Define network policies that deny by default and allow only required paths, such as the web tier reaching the application tier and nothing else.
Namespaces and policy enforcement
Separate workloads by namespace and use admission controls or pod security standards to reject insecure configurations, such as privileged pods, before they run.
Secrets
Kubernetes secrets are only base64-encoded by default. Enable encryption at rest for them, restrict who can read them, and consider an external secrets manager for sensitive credentials.
Protect the supply chain
Containers pull code from many sources: base images, language libraries, and build tools. Maintain a software bill of materials, restrict which registries clusters may pull from, and require that images pass scanning before deployment. Protect the build system with the same rigor as production, because compromising it lets an attacker insert malicious code into every image.
Monitor at runtime
Collect container and cluster logs centrally, including Kubernetes audit logs. Watch for unexpected processes, shells opening inside containers, outbound connections to unusual destinations, and privilege changes. Containers are short-lived, so logs must be shipped away before the container disappears.
Keep the host secure too
Containers are only as safe as the host and orchestrator beneath them. Patch the host operating system, restrict SSH access to nodes, and use a minimal host image designed for running containers.
Getting started in order
If this list feels long, sequence the work. First, scan images and replace bloated base images. Second, stop running as root and remove privileged settings. Third, move secrets out of images and environment files into a managed secrets store. Fourth, add network policies that deny by default. Fifth, centralize logs and add runtime alerts. Each step delivers measurable risk reduction, and together they form a solid foundation that can be extended with signing, policy-as-code, and deeper runtime protection over time.
Common container mistakes
Frequent problems include using the latest tag so builds change unexpectedly, leaving development tools and shells inside production images, storing credentials in environment variables visible to anyone with cluster access, exposing the Kubernetes dashboard or API publicly, and granting broad permissions to a single service account used everywhere. Another is neglecting old images in registries, which retain known vulnerabilities and may be redeployed by accident. Set retention rules for registries and remove images that are no longer needed.
Frequently asked questions
Are containers secure by default?
Not entirely. They provide process isolation, but defaults often favor convenience. Hardening images, privileges, networks, and secrets is necessary.
Why should containers not run as root?
If an attacker breaks into an application running as root inside a container, they have more power to escape or damage the host. A non-root user limits what they can do.
Is scanning images once enough?
No. New vulnerabilities are discovered continuously, so scan at build time and on a recurring schedule, and rebuild images when fixes are available.
Key takeaways
- Use minimal, pinned, scanned images and keep secrets out of them.
- Run as non-root with dropped capabilities, and avoid privileged containers.
- In Kubernetes, use RBAC, network policies, and policy enforcement.
- Log and monitor at runtime; protect the build pipeline and host.
