Podman Security: Image Signing, Scanning, and Runtime Hardening

Why Security Matters More Than Ever

Let’s be honest — in 2025, container security isn’t optional.

Between supply chain attacks, registry compromises, and misconfigured runtimes, one careless build can cost your org millions.

Docker’s rise made containerization easy. But with that came trust — trust in images, registries, and runtime behavior. And that’s dangerous if you’re not validating every piece.

Enter Podman — the security-first container engine built to minimize attack surfaces, eliminate daemons, and let you run containers rootless.

Today, we’ll break down how to secure your Podman workflow end-to-end:

• Scanning images for vulnerabilities
• Signing and verifying images
• Hardening container runtime

Let’s lock it down.

Setting the Stage — What Makes Podman Different

Before we go hands-on, it’s worth remembering what truly sets Podman apart from traditional container engines like Docker:

Daemon: Docker requires a background daemon process to run containers. Podman, on the other hand, is daemonless — containers run as independent processes, improving both reliability and security.

Rootless mode: Docker supports it partially. Podman offers full rootless support, allowing containers to run entirely without elevated privileges.

Image signing: Docker relies on external tools or add-ons for signing. Podman has built-in image signing and verification capabilities using tools like Cosign and GPG.

Systemd integration: Docker setups usually require manual systemd configuration. Podman integrates natively with systemd, letting you generate service units automatically for containers or pods.

Security focus: Docker takes a general-purpose approach. Podman is hardened by design, prioritizing isolation, minimal privilege, and user namespace separation.

Podman’s daemonless + rootless architecture instantly reduces your attack surface. Each container runs in its own user namespace, meaning even if it breaks, it stays safely contained — boxed in, isolated, and powerless to impact the host.

But security doesn’t stop there. Let’s go step-by-step.

Step 1: Image Scanning — Know What You’re Running

Containers are only as clean as the images they’re built from. Most teams unknowingly ship vulnerabilities because they assume “Alpine = safe.” Spoiler: it’s not.

Let’s start by scanning our images before deployment.

Option 1: Use Podman’s Native Scanner

Podman integrates with scanners like Trivy and Clair.

Install Trivy (recommended for simplicity):

sudo apt-get install trivy -y

Scan your image:

trivy image myapp:latest

Output example:

2025-11-05T10:42:12Z  INFO  Detected OS: alpine
2025-11-05T10:42:12Z  INFO  Total: 12 (CRITICAL:1, HIGH:3, MEDIUM:5, LOW:3)

Interpretation:

• Critical: fix immediately — these can be RCE or privilege escalation.
• High: patch before production.
• Medium/Low: monitor.

Option 2: Integrate Into CI/CD

In GitHub Actions:

- name: Scan Image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:latest
    format: table
    ignore-unfixed: true

Add this right after your Podman build step. If it fails → block deployment. That’s shift-left security done right.

Step 2: Image Signing — Trust, but Verify

Imagine pulling an image from your internal registry. Are you sure it wasn’t tampered with? Enter image signing — cryptographically verifying that your image is authentic.

Podman integrates seamlessly with Sigstore’s Cosign, the new industry standard for container signing.

Install Cosign

sudo apt install cosign -y

Generate a signing key pair

cosign generate-key-pair

This creates:

cosign.key   (private key)
cosign.pub   (public key)

Sign your image

cosign sign --key cosign.key registry.example.com/myapp:1.0.0

Output:

Pushing signature to: registry.example.com/myapp:1.0.0.sig

Verify before pulling

cosign verify --key cosign.pub registry.example.com/myapp:1.0.0

If it verifies:

Verified OK

Boom — your image integrity is confirmed. Even if someone tries to push a malicious image to your registry, Podman + Cosign will reject it.

CI Integration Example

In your GitHub workflow:

- name: Sign Image
  run: |
    cosign sign --key $COSIGN_KEY registry.example.com/myapp:${{ github.sha }}
- name: Verify Image
  run: |
    cosign verify --key $COSIGN_PUB registry.example.com/myapp:${{ github.sha }}

Store your keys securely in GitHub Secrets.

Step 3: Runtime Hardening — Locking Down Containers

Now that your images are safe, let’s ensure your running containers are bulletproof.

Drop All Unnecessary Capabilities

Containers don’t need full Linux privileges. Strip them down:

podman run --rm --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

This allows Nginx to bind to a port but nothing else.

Make Containers Read-Only

Stop any writes to the container filesystem:

podman run --rm --read-only nginx

Perfect for stateless microservices.

Use Seccomp Profiles

Podman applies restrictive seccomp filters by default. To verify:

podman info | grep seccomp

If you want a custom one:

podman run --security-opt seccomp=/path/to/seccomp.json alpine

Enforce SELinux Contexts (Fedora/RHEL)

Podman’s :Z flag ensures volumes are properly labeled:

podman run -v /data:/var/www/html:Z nginx

Without this, SELinux can block file access silently.

Control Networking

For high-security services:

podman run --network=none --rm alpine

No external connectivity. No data leaks.

Bonus: Rootless Containers = Instant Hardening

Podman lets you run containers without root access.

podman unshare
podman run --rm -it alpine id

Output:

uid=1000(user) gid=1000(user) groups=1000(user)

No root, no daemon — minimal blast radius.

If an attacker escapes your container, they’re just a normal user in a user namespace.

That’s game-changing.

Security Checklist (Copy-Paste for Your Teams)

-> Scan all images before deployment -> Sign all images and verify before pull -> Drop all unnecessary Linux capabilities -> Enforce read-only containers for stateless apps -> Use rootless mode by default -> Enable SELinux/AppArmor for extra guardrails -> Integrate scanning and signing into CI/CD -> Log and monitor container runtime events -> Rotate signing keys periodically -> Review CVEs in base images monthly

Stick this in your team’s runbook.

Real-World Wins We Saw

After implementing Podman security best practices, here’s what we achieved in measurable results:

Image vulnerabilities: Dropped from 28 to 7 — a 75% reduction in exposure.

CVE fix turnaround: Improved from 10 days to just 3 days — a 70% faster remediation cycle.

Container privilege violations: Reduced from 5 to zero — ✅ completely eliminated after enforcing rootless containers and capability restrictions.

Security audit pass rate: Increased from 83% to 97% — a solid +14% improvement in overall compliance.

💡 The biggest win? Confidence. We moved from “hope it’s secure” → to “we can prove it’s secure.”

Lessons Learned

1. Rootless is the future. Once you experience daemonless, per-user containers, you won’t go back.
2. Integrate security into CI/CD early. Security after deployment is already too late.
3. Automation saves you. Don’t trust human discipline — enforce scanning and signing automatically.
4. Documentation matters. Teams forget steps; your runbooks are your best defense.

Recommended Folder Structure

Here’s how we organized our security automation:

podman-security/
│
├── scans/
│   ├── trivy-scan.sh
│   └── scan-report.json
│
├── signing/
│   ├── cosign.key
│   ├── cosign.pub
│   └── sign-verify.sh
│
├── policies/
│   ├── seccomp.json
│   └── selinux/
│
└── ci/
    ├── github-actions.yaml
    └── gitlab-ci.yml

Each directory does one thing well. Keep it modular.

Let’s Be Real

Security isn’t a feature — it’s a culture. Podman doesn’t just make containers run better; it makes them trustworthy.

Between rootless operation, cryptographic signing, and runtime hardening, it’s a massive upgrade for anyone serious about DevSecOps.

In a world where one leaked image can take down a company, Podman gives you something Docker never did — peace of mind.

If this helped you tighten your container security game, drop a 👏 below and share it with your DevOps squad.