# Is Container Isolation a Lie? That Thin Line Between Docker Socket and Host

> If you think your containers are bulletproof shells, think again. From Docker socket abuse to risky capabilities, let's talk about how that 'sandbox' can vanish in seconds and how to actually secure it.

- Author: Sedat Özdemir (Sr. Expert Pentest & Vulnerability Management Engineer)
- Date: 2026-03-19
- Category: devsecops · Tags: container-security, devsecops, docker, kubernetes, red-teaming
- URL: https://sedatozdemir.com.tr/en/blog/konteyner-izolasyonu-bir-yalan-mi-docker-socketten-hosta-uzanan-o-ince-cizgi

The moment you run `docker run --privileged -v /:/host alpine:latest`, you realize that 'secure' sandbox is just an illusion; the host OS is now your playground.

Hey everyone. Today, let’s look at this whole container security thing—not from the technical director's chair, but from the perspective of a Red Teamer who's both defending and trying to punch holes in those defenses on the field. As most of you know, a container isn't a Virtual Machine (VM). It's a set of processes sharing a kernel, restricted only by namespaces and cgroups. Yet, we often act like there are impenetrable walls around them. In the tests we run at testCompany, the biggest mistake we see is failing to realize exactly where that thin line ends.

### Docker Socket: Putting the House Keys Under the Doormat

I often see the `docker.sock` file being mounted into containers in many CI/CD pipelines or monitoring tools. If an attacker manages to execute code in a container that has access to this socket, it's game over. Access to the Docker socket means full access to the Docker API.

Let’s look at a defanged scenario. What actually happens when an attacker runs this command from inside the container?

```bash
# An attacker with Docker socket access becoming root on the host
curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" \
  -d '{"Image": "alpine", "Cmd": ["/bin/sh", "-c", "chroot /host /bin/sh"], "Binds": ["/:/host"]}' \
  http://localhost/containers/create
```

This request tells the Docker daemon to create a new container but mount the host's root directory into itself. The result? A fully privileged shell on the host machine. If you're giving `docker.sock` to a container, you've basically accepted that the container is now the host itself. The fix is simple: Never share the socket. If you need to talk to the Docker API, do it behind a restricted proxy or use mTLS.

### Privileged Containers and Capabilities

Then there's the infamous `--privileged` flag. My DevOps friend, when you flip this switch because 'the app is throwing errors, permissions aren't enough,' you've actually pulled the pin on a grenade. A privileged container gets almost all kernel capabilities on the host.

Linux Capabilities break down root privileges into pieces. For instance, `CAP_NET_BIND_SERVICE` only lets you open low ports, while `CAP_SYS_ADMIN` is like a Swiss Army knife; you can mount filesystems, change namespaces, and more.

In Red Team ops, our favorite things are over-privileged containers. For example, if a container only has the `CAP_SYS_PTRACE` capability, it can read the memory of other processes on the host and maybe dump an admin password from there.

**What to do?**

To shrink the attack surface, the 'Least Privilege' principle applies here too. Use `securityContext` in your Dockerfile or Kubernetes deployment:

```yaml
# A secure example for Kubernetes
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE
  runAsNonRoot: true
```

By dropping `ALL` capabilities and only adding what is strictly necessary, you turn a potential disaster into a minor incident. Stay safe out there, and remember: isolation is only as strong as your configuration.