"We're using containers, man. Everything is isolated, no connection to the outside world." Whenever I hear someone say this, I usually just give them a small smile. Truth is, that "box" you feel so safe in is actually just made of cardboard if it’s not configured right. Most of the time, you're even leaving the keys right in the lock.
I saw this in a recent pentest. These guys had built a massive microservices architecture—Kubernetes was flying everywhere. But once we got inside, we saw that almost every container was running as the root user. Even worse? The Docker socket was mounted directly into the containers. They basically locked the front door but left the key hanging on the knob.
Why Being Root is a Massive Headache
A lot of my developer friends forget to use the USER command in their Dockerfile, or they just skip it because they don't want to deal with permission issues. "Let it just work," they say. But look, being root inside a container is a giant step toward becoming root on the host machine.
If an attacker finds a vulnerability in your app (and trust me, they will), they’re in with root privileges immediately. From there, it's just a matter of their imagination.
Honestly, it takes maybe 5 seconds to add this to your Dockerfile:
# Bad example: Runs as root by default
FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]
# Good example: Create your own user
FROM node:18-alpine
# Create a group and user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
# Change ownership of the files
COPY --chown=appuser:appgroup . .
USER appuser
RUN npm install
CMD ["node", "index.js"]
Think about it: why would a container running in production ever need root? If it’s just reading files and responding to web requests, appuser is more than enough.
The Docker Socket: Your Biggest Weakness
Pay attention to this one because it's critical. The moment you mount /var/run/docker.sock into a container, you’re basically telling that container, "You own this machine." If an attacker gets access to that socket, they can start new containers, stop existing ones, and even access the host's file system.
During one pentest, we found a monitoring tool that had access to the Docker socket. We used that socket to spin up a new "privileged" container that mounted the entire host disk under /mnt. The result? We had the host’s /etc/shadow file in minutes. Every password on the system was ours.
If you don't absolutely need the Docker socket (and 99% of the time, you don't), never add it to your volumes. If you need it for CI/CD processes, I'd suggest looking into more secure alternatives like Kaniko instead of Docker-in-Docker (DinD).
"Privileged" Containers: Giving Away a Blank Check
Every now and then, I see someone running docker run --privileged .... When I ask why, the answer is usually, "Well, it was the only way it would work; I kept getting permission errors." Look, that’s like using a bazooka to kill a fly.
Running a privileged container bypasses almost all the security boundaries Docker provides. It gives the container access to the host's hardware and kernel features. In the hands of a hacker, that’s not just a vulnerability—it's a total system takeover.
In short, don't take the "isolation" of containers for granted. Take a look at your Dockerfiles today. Are you really "isolated," or are you just one exploit away from losing the whole server?