Container Security

🏰 Docker Container Security: Building Walls Around Your Apps

The Castle Analogy

Imagine you have a magical kingdom where different families live. Each family wants to live in their own castle, with their own space, their own food, and their own rules. But here’s the tricky part—they’re all sharing the same land!

That’s exactly what Docker containers do! They let different apps live on the same computer, but each one thinks it has its own private castle. Let’s explore how Docker builds these magical walls!

🧱 Container Isolation Mechanisms

What is Container Isolation?

Think of isolation like having invisible walls between playground areas. Kids in one area can’t see or touch things in another area, even though they’re in the same park.

graph TD
    A["One Computer"] --> B["Container 1 🏰"]
    A --> C["Container 2 🏰"]
    A --> D["Container 3 🏰"]
    B --> E["Can't see C or D]
    C --> F[Can't see B or D"]
    D --> G[Can't see B or C]

How Docker Creates These Walls:

Simple Example: Container A runs a website. Container B runs a database. Container A cannot peek into Container B’s files or memory—even though they share the same computer!

🎭 Linux Namespaces: The Magic Glasses

What Are Namespaces?

Imagine everyone wears special glasses. When you wear YOUR glasses, you only see YOUR toys, YOUR room, and YOUR name on the door. Someone else wearing THEIR glasses sees completely different things!

Namespaces are like these magic glasses for containers.

The 6 Types of Namespace Glasses

graph TD
    N["Namespaces"] --> P["PID 🔢"]
    N --> M["Mount 📁"]
    N --> U["UTS 🏷️"]
    N --> I["IPC 💬"]
    N --> NET["Network 🌐"]
    N --> USER["User 👤"]
    P --> P1["See only your processes"]
    M --> M1["See only your files"]
    U --> U1["Have your own hostname"]

Each Namespace Explained Simply

1. PID Namespace 🔢 (Process ID)

• Your container sees process #1, #2, #3
• Another container ALSO sees #1, #2, #3
• But they’re completely different processes!
• Like two classrooms both having “Student #1”

2. Mount Namespace 📁 (Files)

• Your container sees /app/myfiles
• It can’t see /app/theirfiles from another container
• Like each family has their own toy box

3. UTS Namespace 🏷️ (Hostname)

• Your container can call itself “web-server”
• Another container calls itself “database”
• They don’t know about each other’s names!

4. IPC Namespace 💬 (Talking)

• Containers talk using special channels
• One container’s channels are invisible to others
• Like having a private walkie-talkie frequency

5. Network Namespace 🌐 (Internet)

• Each container gets its own network card
• Its own IP address
• Its own ports
• Like each family has their own phone number

6. User Namespace 👤 (Who You Are)

• Root (admin) inside container ≠ root outside
• A container’s “superuser” has limited real power
• Like being “King” in a game of pretend

Real Example

# Look at processes INSIDE container
docker exec myapp ps aux
# Shows: PID 1 (nginx)

# Look at processes OUTSIDE (host)
ps aux | grep nginx
# Shows: PID 28547 (same nginx!)

The same app has different PID numbers depending on who’s looking!

🍕 Control Groups (cgroups): The Fair Sharing Rules

What Are Control Groups?

Imagine you have 10 pizza slices for the whole party. Without rules:

• One hungry kid might eat ALL 10 slices! 😱
• Other kids get nothing!

Control Groups are the “fair sharing” rules that make sure everyone gets their portion.

What Cgroups Control

graph TD
    C["Cgroups Control"] --> CPU["🧠 CPU Time"]
    C --> MEM["💾 Memory"]
    C --> IO["💿 Disk Speed"]
    C --> NET["📡 Network Speed"]
    CPU --> C1["Max 50% of brain power"]
    MEM --> M1["Max 512MB of memory"]
    IO --> I1["Max 100MB/s disk"]

Real-World Example

# Run container with memory limit
docker run -m 512m myapp

# Run with CPU limit (50% of one core)
docker run --cpus="0.5" myapp

# Run with both limits
docker run -m 256m --cpus="0.25" myapp

Why This Matters:

• One broken app can’t crash the whole computer
• One greedy app can’t hog all resources
• Everything stays fair and stable!

Simple Comparison

⚔️ Linux Capabilities: Giving Only What’s Needed

What Are Capabilities?

In the old days, you were either:

• Root (Superuser): Can do EVERYTHING 👑
• Regular User: Can do very little 😔

This was dangerous! If an app needed just ONE special power, you had to give it ALL powers!

Capabilities split the superpower into 40+ tiny powers. Now you can give apps ONLY what they need!

Think of It Like Superhero Powers

graph TD
    A["Root = ALL POWERS"] --> B["Too Dangerous!"]
    C["Capabilities = Pick Powers"] --> D["Much Safer!"]
    D --> E["🌐 NET_BIND_SERVICE"]
    D --> F["📂 SYS_CHROOT"]
    D --> G["⏰ SYS_TIME"]
    D --> H["Only what you need!"]

Common Capabilities Explained

Docker Drops Dangerous Capabilities

By default, Docker removes these dangerous powers:

• ❌ SYS_ADMIN (too powerful!)
• ❌ NET_ADMIN (change network settings)
• ❌ SYS_MODULE (load kernel code)

Adding/Removing Capabilities

# Drop ALL capabilities, add only one
docker run --cap-drop=ALL \
           --cap-add=NET_BIND_SERVICE \
           nginx

# See what capabilities a container has
docker inspect mycontainer \
  --format='{{.HostConfig.CapDrop}}'

The Golden Rule: Give the LEAST powers possible. Drop what you don’t need!

📖 Read-Only Containers: No Writing Allowed!

What Is a Read-Only Container?

Imagine a museum where you can LOOK at everything but TOUCH nothing. That’s a read-only container!

The app can:

• ✅ Read files
• ✅ Run code
• ❌ Change files
• ❌ Write new files
• ❌ Delete anything

Why Is This Powerful?

graph TD
    A["Hacker Breaks In"] --> B{Container Type?}
    B --> |Normal| C["Writes malware 😈"]
    B --> |Read-Only| D[Can't write! 🛡️]
    C --> E["System infected"]
    D --> F["Attack fails!"]

Making a Container Read-Only

# Start container in read-only mode
docker run --read-only nginx

# But wait! Apps sometimes NEED to write
# Create exceptions with tmpfs:
docker run --read-only \
  --tmpfs /tmp:rw,noexec,nosuid \
  --tmpfs /var/run:rw,noexec,nosuid \
  nginx

What’s tmpfs?

Temporary storage in RAM (memory). It:

• Disappears when container stops
• Doesn’t touch the real disk
• Perfect for logs and temp files!

Real-World Example

🔒 No-New-Privileges Flag: No Power-Ups!

What Is No-New-Privileges?

Imagine playing a video game where you START with certain powers. The “no-new-privileges” rule says:

“You can NEVER gain more powers during the game!”

Even if you find a magic sword, it won’t make you stronger. You’re locked at your starting level.

Why Does This Matter?

Some attacks work by escalating privileges:

1. Hacker enters as weak user 😈
2. Finds a bug that gives them more power
3. Becomes admin/root 👑
4. Takes over everything!

No-new-privileges stops step 2!

graph TD
    A["Attacker enters as user"] --> B{no-new-privileges?}
    B --> |No| C["Can escalate to root! 😈"]
    B --> |Yes| D["Stuck as user forever 🛡️"]
    C --> E["System compromised"]
    D --> F["Attack limited!"]

How to Enable It

# Run with no-new-privileges
docker run --security-opt=no-new-privileges \
           myapp

# Check if it's enabled
docker inspect mycontainer \
  --format='{{.HostConfig.SecurityOpt}}'

What Gets Blocked?

Real-World Setuid Example

The ping command normally needs special powers. Without the flag:

# Ping uses setuid to get network power
./ping google.com  # Works!

With no-new-privileges:

# Setuid is ignored, ping can't get power
./ping google.com  # Permission denied!

🛡️ Putting It All Together: The Ultimate Defense

Each security layer adds protection. Together, they’re nearly unbreakable!

graph TD
    A["Your Container"] --> B["Namespaces 🎭"]
    B --> C["Cgroups 🍕"]
    C --> D["Capabilities ⚔️"]
    D --> E["Read-Only 📖"]
    E --> F["No-New-Privileges 🔒"]
    F --> G["Super Secure! 🏆"]

The Perfect Secure Container

docker run \
  --read-only \
  --tmpfs /tmp \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt=no-new-privileges \
  -m 512m \
  --cpus="0.5" \
  nginx

This container:

• 🎭 Has isolated namespaces (automatic)
• 🍕 Limited to 512MB RAM and 50% CPU
• ⚔️ Only has NET_BIND_SERVICE capability
• 📖 Cannot write to filesystem
• 🔒 Cannot gain new privileges

You just built a fortress! 🏰

🎯 Key Takeaways

1. Namespaces = Each container sees its own private world
2. Cgroups = Fair sharing of CPU, memory, disk
3. Capabilities = Give tiny powers instead of ALL powers
4. Read-only = No writing, no tampering
5. No-new-privileges = No power-ups for attackers

Remember our castle analogy:

Each family (container) lives in their own castle (namespace), gets their fair share of food (cgroups), has only the keys they need (capabilities), can’t rebuild the walls (read-only), and can’t steal the king’s crown (no-new-privileges)!

Now go forth and build secure containers! 🚀