Introduction: Why This Matters (Especially on Parrot)
If you're running Parrot Security Edition and wondering whether to stick with Docker or switch to Podman, you're asking the right question. As security-conscious developers, we care about isolation, privilege escalation risks, and maintaining a hardened system.
Here's the reality: Docker has been the containerization gold standard for a decade. But Podman changes the game for security-first systems.
This post walks you through:
The fundamental differences (and why they matter)
Rootless containers: why they're a big deal
Practical side-by-side examples (setup, running containers, building images)
When to use Podman vs Docker (honest tradeoffs)
How to migrate if you're switching
Let's dive in.
The Core Difference: Root vs Rootless
Docker (The Traditional Way)
User Command
↓
Docker Daemon (runs as root)
↓
Container (inherits root privileges)
Docker works by running a central daemon as root. You interact with it as a regular user, but behind the scenes, the daemon—running with elevated privileges—creates and manages containers.
What does this mean for you?
If someone escapes your container, they have root access to your entire system
The Docker daemon is a single point of failure
On Parrot (a security-focused distro), this adds unnecessary attack surface
Podman (The Security-First Approach)
User Command
↓
Podman (user-level process)
↓
Container (runs with user privileges, no daemon needed)
Podman runs as your regular user, no daemon, no root escalation. Containers are isolated at the user level.
What does this mean for you?
If a container is compromised, the attacker gets your user privileges—not root
No privileged daemon listening on the system
Naturally aligned with security principles (least privilege)
Why This Matters: A Real Scenario
Imagine you're running a web server in a container:
With Docker:
Container gets compromised via a web vulnerability
Attacker has root access to your system
They can modify kernel parameters, install rootkits, access other containers
With Podman (rootless):
Same container, same vulnerability, same compromise
Attacker has your user privileges, not root
They're sandboxed to your user's scope
System integrity remains intact
In security terms: Podman defaults to the principle of least privilege. Docker requires you to opt into it.
Side-by-Side Comparison Table
Feature | Docker | Podman |
Daemon | Central daemon (runs as root) | No daemon (user-level process) |
Rootless | Supported (but requires setup) | Default behavior |
Setup Complexity | Simple, well-documented | Slightly more involved |
Container Isolation | User namespace isolation (optional) | Built-in user namespace isolation |
Pod Support | No native pod concept | Native pod support (like Kubernetes) |
API Compatibility | Industry standard | Docker-compatible API |
Image Compatibility | Industry standard (OCI) | 100% OCI compatible |
Learning Curve | Steep but worth it | Moderate (Docker knowledge transfers) |
Production Use | Ubiquitous in enterprise | Growing adoption in K8s-native environments |
Security by Default | No | Yes |
Installation on Parrot OS
Installing Docker
bash
# Update package lists
sudo apt update
# Install Docker
sudo apt install docker.io
# Add your user to docker group (enables root escalation!)
sudo usermod -aG docker $USER
# Verify installation
docker --version
⚠️ Security note: Adding your user to the docker group is equivalent to granting sudo access. Read why.
Installing Podman
bash
# Update package lists
sudo apt update
# Install Podman
sudo apt install podman
# Verify installation
podman --version
# No special user group needed—run as your regular user
podman ps
Notice the difference? Podman just works. No privilege escalation needed.
Hands-On: Running Your First Container
With Docker
bash
# Pull a simple web server image
docker pull nginx:latest
# Run a container
docker run -d -p 8080:80 --name webserver nginx:latest
# Check running containers
docker ps
# View logs
docker logs webserver
# Stop and remove
docker stop webserver
docker rm webserver
With Podman (Same Syntax!)
bash
# Pull the same image
podman pull nginx:latest
# Run a container
podman run -d -p 8080:80 --name webserver nginx:latest
# Check running containers
podman ps
# View logs
podman logs webserver
# Stop and remove
podman stop webserver
podman rm webserver
Notice: The commands are identical. This is by design—Podman is deliberately Docker-compatible.
Building Images: Docker vs Podman
Dockerfile (Works for Both)
Create a simple Dockerfile:
dockerfile
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
Docker: Build and Push
bash
# Build image
docker build -t myapp:1.0 .
# Tag for registry
docker tag myapp:1.0 yourregistry/myapp:1.0
# Push to registry
docker push yourregistry/myapp:1.0
# Run
docker run -d --name app myapp:1.0
Podman: Build and Push
bash
# Build image (rootless, no daemon needed)
podman build -t myapp:1.0 .
# Tag for registry
podman tag myapp:1.0 yourregistry/myapp:1.0
# Push to registry
podman push yourregistry/myapp:1.0
# Run
podman run -d --name app myapp:1.0
Same workflow, same results, but Podman does it without needing root privileges in the background.
The Pod Concept (Podman's Killer Feature)
Podman has something Docker doesn't: native pod support.
In Kubernetes, a pod is a group of containers that share network and storage. Podman lets you create pods locally:
bash
# Create a pod
podman pod create --name mypod -p 8080:8080
# Run containers in the same pod
podman run -d --pod mypod --name webserver nginx:latest
podman run -d --pod mypod --name app myapp:1.0
# Containers share the pod's network
podman ps -a
# Inspect the pod
podman pod inspect mypod
Why is this useful?
Local Kubernetes testing: You can test pod behavior on your machine before deploying to K8s
Multi-container services: Services that need tight coupling can share a pod
Better than Docker Compose for simple cases (though Docker Compose still has a place)
Rootless Containers in Action
Docker Rootless Mode (Requires Setup)
Docker can run rootless, but it's not the default:
bash
# Install Docker rootless mode
dockerd-rootless-setuptool.sh install
# Start rootless Docker daemon
systemctl --user start docker
# Now Docker runs without root
docker ps
Podman Rootless (Just Works)
bash
# Already rootless by default
podman ps
# No setup, no daemon, no privilege escalation
# Just works™
Podman's approach is cleaner because it's the default, not an opt-in feature.
Performance: Do They Differ?
Short answer: Not significantly for most use cases.
Benchmark results vary by workload:
Container startup: Podman is often faster (no daemon communication overhead)
Image building: Similar performance
Runtime performance: Near identical (both use runC or crun)
Real-world impact: Negligible. Choose based on security and philosophy, not speed.
When to Use Docker
✅ Docker is the right choice if:
You're in an enterprise environment where everyone uses Docker
Your team is already trained on Docker workflows
You need guaranteed support and tooling from every vendor
You're deploying to managed Kubernetes services (EKS, GKE) that expect Docker-compatible runtimes
You're comfortable with the security tradeoffs (or mitigating them with rootless setup)
When to Use Podman
✅ Podman is the right choice if:
You're on Parrot OS or another security-focused distro
You want security by default (rootless containers, no daemon)
You're preparing for Kubernetes (Podman's pod concept mirrors K8s)
You prefer a daemonless architecture (process management is simpler)
You want to avoid adding your user to privileged groups
You're building a security-conscious workflow
Migration: From Docker to Podman
If you're switching, it's surprisingly simple.
Step 1: Stop Docker
bash
sudo systemctl stop docker
sudo systemctl disable docker
Step 2: Install Podman
bash
sudo apt install podman
Step 3: Migrate Existing Images
bash
# List Docker images
docker images
# Save Docker images to tar (if you want to preserve them)
docker save myimage:latest -o myimage.tar
# Load into Podman
podman load -i myimage.tar
Or, just re-pull from registries (images are registry-agnostic):
bash
podman pull yourregistry/myapp:1.0
Step 4: Update Scripts and Workflows
Replace docker with podman in scripts:
bash
# Before
docker run -d nginx
# After
podman run -d nginx
Most scripts will work without modification because of Podman's Docker compatibility.
Advanced: Rootless Networking on Podman
One gotcha with rootless Podman: port binding below 1024 requires extra setup.
bash
# This won't work for ports < 1024 in rootless mode
podman run -p 80:80 nginx # Error: permission denied
# Use ports >= 1024
podman run -p 8080:80 nginx # Works!
Solution for port 80:
bash
# Enable unprivileged port binding
sudo sysctl net.ipv4.ip_unprivileged_port_start=80
# Or use a reverse proxy (recommended for production)
podman run -p 8080:80 nginx
# Then proxy external port 80 to internal 8080
Docker Compose and Podman Compose
Docker Compose (Docker's Orchestration)
yaml
version: '3'
services:
web:
image: nginx:latest
ports:
- "8080:80"
app:
image: myapp:1.0
environment:
- DB_HOST=db
db:
image: postgres:13
environment:
- POSTGRES_PASSWORD=secret
bash
docker-compose up
Podman Compose (Podman's Equivalent)
Install podman-compose:
bash
pip install podman-compose
Same YAML file works:
bash
podman-compose up
Or use Podman pods for simpler use cases:
bash
podman pod create --name myapp -p 8080:80
podman run -d --pod myapp --name web nginx:latest
podman run -d --pod myapp --name app myapp:1.0
podman run -d --pod myapp -e POSTGRES_PASSWORD=secret --name db postgres:13
Security Best Practices
For Docker
bash
# Run containers as non-root user
docker run -u 1000:1000 myapp:1.0
# Use read-only filesystems where possible
docker run --read-only -v /tmp --name app myapp:1.0
# Limit resources
docker run -m 256m --cpus=0.5 myapp:1.0
# Don't run in privileged mode
# docker run --privileged # ❌ Almost never do this
For Podman (Already More Secure)
bash
# Rootless by default—already more isolated
podman run myapp:1.0
# Still apply the same hardening practices
podman run -u 1000:1000 --read-only -m 256m --cpus=0.5 myapp:1.0
Real-World Workflow: Security Professional
Here's how a security-conscious developer (like you) might use Podman on Parrot:
bash
# 1. Pull a CTF/pentesting tool image
podman pull kalilinux/kali:latest
# 2. Run in an isolated rootless container
podman run -it --name penetest kalilinux/kali:latest
# 3. Use Podman pods for multi-tool workflows
podman pod create --name pentest-suite
podman run -d --pod pentest-suite --name metasploit metasploit/metasploit:latest
podman run -d --pod pentest-suite --name burp portswigger/burp-suite:latest
# 4. Remove after testing (containers are ephemeral)
podman pod rm -f pentest-suite
# 5. Check resource usage (no daemon overhead)
podman stats
# 6. For production, push to registry (same as Docker)
podman tag myapp:1.0 registry.example.com/myapp:1.0
podman push registry.example.com/myapp:1.0
Troubleshooting Common Issues
Issue: "permission denied: /var/run/docker.sock"
With Docker: You need to add your user to the docker group (which is a security risk):
bash
sudo usermod -aG docker $USER
With Podman: Just use it—no socket, no permission issues.
Issue: Port Binding Fails
With Podman (rootless): Use ports >= 1024 or configure net.ipv4.ip_unprivileged_port_start:
bash
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80
Issue: Images Not Found
Both Docker and Podman search registries in a specific order. Set your registry preference:
bash
# Podman config
vi ~/.config/containers/registries.conf
[registries.search]
registries = ['docker.io', 'quay.io']
Conclusion: Which Should You Choose?
For Parrot OS, I recommend Podman for these reasons:
Security is the default, not an afterthought
No privilege escalation required (aligns with Parrot philosophy)
Daemonless architecture (simpler, more transparent)
Pod support (great for learning Kubernetes locally)
Identical Docker syntax (zero learning curve)
But Docker isn't wrong:
It's ubiquitous in enterprise
Better tool support and documentation
More developers know it
Requires conscious security setup, but you can do it
What's Your Setup?
Are you running Docker or Podman on Parrot? What's your use case—development, pentesting, infrastructure?
Drop a comment below with your containerization workflow. I'd love to hear how you're using containers for security work.
Comments
Post a Comment