Containers changed how teams build and deploy software. They’re lightweight, portable, and fast to spin up. They’ve also introduced a set of security challenges that many development teams haven’t caught up with yet.
The speed that makes containers so appealing for development can work against security when teams push images to production without adequate checks. A container that works isn’t necessarily a container that’s safe.
Insecure Base Images
Every container starts with a base image, and that image carries whatever vulnerabilities the underlying packages contain. Development teams frequently pull base images from public registries, build their application on top, and push to production without scanning the result.
Those base images can contain dozens of known vulnerabilities. Some critical. Some with public exploits. And because the image gets deployed across multiple environments, a single vulnerable base image can expose your entire infrastructure.
William Fieldhouse, Director of Aardwolf Security Ltd, comments: “Container environments give teams a false sense of isolation. During assessments, we regularly find containers running as root, mounting the host filesystem, and using base images with known critical vulnerabilities. One misconfigured container can compromise the entire orchestration cluster.”
Running as Root and Privilege Escalation
Containers that run as root inside the container are one misconfiguration away from running as root on the host. Kernel exploits, volume mount misconfigurations, and Docker socket exposure can all allow a container breakout that gives the attacker host-level access.
The principle of least privilege applies to containers just as much as it applies to user accounts. Run processes as non-root users inside containers. Use read-only filesystems where possible. Drop capabilities that the application doesn’t need.
Secrets Management in Container Environments
Environment variables remain the most common way to pass secrets to containers, and they’re also the least secure. Environment variables get logged, they appear in process listings, and they persist in container metadata that’s accessible to anyone with API access to the orchestration platform.
Dedicated secrets management tools integrate with container orchestrators to provide secrets at runtime without exposing them in configuration files or environment variables.
Testing Container Security
Include your containerised applications in your web application penetration testing programme. Test the applications themselves, but also test the orchestration layer. Can you access the Kubernetes API? Are there misconfigured RBAC policies? Can you escape from a container to the host?
If you’re running containerised applications in production and haven’t had them professionally assessed, getting a penetration test quote will help you understand whether your container security matches your risk appetite. The flexibility of containers is only an advantage if the security keeps pace with the deployment speed.
