6 Container Security Blind Spot I Missed The First Time
Hey There,
Securing containers is the one of the powerful skill you can learn today.
The first time I reviewed docker security , I focused on these 3 things:
👉 Keeping images updated.
👉 Scanning for vulnerabilities.
👉 Using Private Registry.
It wasn't until a peer review that multiple risks were found, and I realised how much I had overlooked.
If you’re starting your cloud security journey, unaware about container security risk and don’t know where to get started, this this post is for you.
By end of the post you’ll, have checklist to get you started and feel confident for your future review.
I have been Cybersecurity for 11 years and have performed dozens of container security review. Learning to identity blind spots early helped improved the speed of my assessment.
So, here’s 6 blind spots I missed the first time—and how you can avoid the same mistakes.
Let’s dive in.
Blind Spot#1 Running Container as Root
Under docker, a non-root user on host when initiate a containers, it runs as Root by default which is form of privilege escalation. Moreover, Root inside the container is Root on the host.
Root is highest level of privilege.
If an attacker can escape a container that is running as root, they have full root access to the host, which means free access to everything on the machine. This compromise could further escalate on flat network allowing attackers to move laterally within the network.
So what’s the fix ?
Build/Deploy container with non-root users.
Run a root less containers.
Blind Spot#2 Exposing the Docker socket to Container
Docker socket “/var/run/docker.sock” is the UNIX socket that Docker is listening to. This is the primary entry point for the Docker API. The owner of this socket is root.
Why this is bad ?
Giving container access to socket is equivalent to giving unrestricted root access to your host. Because we learned in Blind Spot#1, that container run as root by default and if escapes the container will have root on host.
What to do instead?
Use proxy solution to apply rules that would filter the request to the Docker socket, limiting the attack surface for containers.
Examples of proxy solution includes
Docker Socket Proxy from Linuxserver.io
Socket proxy from Tecnative.
Blind Spot#3 Overly permissive Linux Kernel Capabilities
Linux has over 30 capabilities that can be assigned to a process/thread.
It determine whether that thread can perform certain actions. For example, a thread needs:
CAP_NET_BIND_SERVICE capability in order to bind to a low-numbered (below 1024) port.
CAP_SYS_BOOT so that arbitrary executables don’t have permission to reboot the system.
CAP_SYS_MODULE is needed to load or unload kernel modules.
You can consult “man capabilities” on a Linux machine for detailed information on capabilities.
Root and non-root user have different set of capabilities. For example, ping command requires CAP_NET_RAW capability to run which is not enabled for a non-root user.
You can “capsh --print | grep Current” to get list of capabilities. For example,
docker run --rm -it --privileged alpine sh -c ‘apk add -U libcap; capsh --print | grep Current’
What to do instead?
Once you have know the list of capabilities, drop unnecessary privileges using --cap-drop or add missing --cap-add.
Blind Spot#4 Not Limiting Resources
When you start a container, the runtime creates new cgroups.
Cgroups also known as Control Groups limit the resources, such as memory, CPU, and network input/output, that a group of processes can use. From a security perspective, well-tuned cgroups can ensure that one process can’t affect the behavior of other processes.
For example, using all the CPU or memory to starve other applications or denying the resources to other application also know DoS(Denial of Service) attack.
In multi-container environment, we do not want that.
What to do instead?
Limit memory, CPU usage, maximum number of restarts and processes
Use flags such as —memory or —cpu in command line or set the cpu and memory attribute in docker compose.yaml or pod definition file to restrict the resources.
Blind Spot#5 Write permission on filesystem
Preventing an executable from running in a container if that executable wasn’t present in the image when it was created/scanned, is known as drift prevention.
Downloading additional software into its filesystem after container starts running is considered very bad idea. Here’s why ?
Different version of container may exist making it difficult to reproduce.
It may introduce software supply chain risk if malicious packages makes it way to the host by escaping the container. And as we learned above, root on container is root on host.
What to do instead?
Making container Immutable is considered a best practice.
Run with --read-only flag.
Deploy Golden Image Container with pre-installed software required for the containers.
Install security tools that can alert when downloading of packages at runtime.
Blind Spot#6 Not setting logging level
The OWASP site shares that, on average, breaches take almost 191 days to be identified in 2016.
In 2025, the number must have been reduced due sufficient observation combined with alerting on unexpected behavior.
But, many organisation still fails to log and monitor the container events.
What’s the solution ?
Set the logging level to at least INFO
What should you log ?
You should be logging following container events(atleast)
Container start/stop events, including the identity of the image and the invoking user
Access to secrets.
Any modification of privileges.
Modification of container payload, which could indicate code injection.
Inbound and outbound network connections.
Volume mounts (for analysis of mounts that might subsequently turn out to be sensitive)
Failed actions such as attempts to open network connections, write to files, or change user permissions, as these could indicate an attacker performing reconnaissance on the system
Conclusion
Each of these checks could eliminate massive risks.
If you’re running Docker in production, double-check these settings now.
The sooner you fix them, the fewer surprises you’ll face later.
Chat Soon,
Kushal
What did you think of today’s newsletter?
❤️ Loved it? → Refer it to a friend or drop a ‘Like‘ below.
🥳 Just joined? → Start here: 9 Security Principals Beginners Must Know
💡 Have ideas? → Hit reply and tell me how I can make this more useful for you.