A hands-on Docker and container security guide built around reproducible labs, attack scenarios, defensive controls, and production-oriented validation.
The repository progresses from foundational Docker hardening to runtime escape analysis, secrets management, software supply-chain trust, AI-assisted remediation, and AI context-poisoning defenses.
- Security auditing: Docker Bench Security and CIS-aligned checks
- Container hardening: least privilege, Linux capabilities, read-only filesystems, and resource controls
- Vulnerability management: Trivy, Syft, Grype, SBOMs, and policy enforcement
- Image trust: Cosign signing, provenance, attestations, and admission controls
- Seccomp: application-specific syscall filtering
- Network security: segmentation, internal networks, TLS, and misconfiguration testing
- Runtime security: Docker socket exposure, privileged containers, dangerous capabilities, host mounts, and
/procor/sysexposure - Secrets management: Docker Swarm secrets, Vault, BuildKit secrets, secret scanning, and audit evidence
- AI workload security: ML container controls, secured MCP tool access, and AI context-poisoning defenses
- Trust governance: hardened images, Kyverno policies, signed attestations, and fleet drift analysis
This guide is part of OpsCart Labs, a collection of open-source, hands-on labs informed by production cloud and Kubernetes operations.
Docker Security: A Practical Guide — this repository
- 13 labs covering Docker security from auditing through AI context defense
- Reproducible scripts, configurations, policies, and captured experiment evidence
- Status: active development
Certified Kubernetes Administrator Exam Prep
- Hands-on CKA preparation labs
- Automated validation and operational notes
- Status: active development
- Built from practical Docker, Kubernetes, cloud, and DevOps experience
- Designed around reproducible scenarios rather than theory alone
- Maintained in public Git repositories
- Intended for engineers, security practitioners, auditors, and platform teams
Use this section as the central entry point for the repository.
| Area | Purpose |
|---|---|
| Lab Catalog | Select a hands-on lab by security domain or learning level |
| Publications and Research | Connect formal research, CNCF publications, practitioner articles, and implementation evidence |
| Additional Resources | Browse official documentation, standards, security tools, and primary research |
| Setup Guide | Prepare Docker, shared tooling, and the common lab environment |
| Troubleshooting Guide | Diagnose shared Docker, Compose, networking, tooling, and Kubernetes problems |
| Repository Issues | Report broken links, reproducibility problems, or documentation corrections |
- New to the repository: Setup Guide → Lab Catalog → Lab 01
- Docker or container security practitioner: Lab Catalog → Labs 02–10
- Supply-chain or platform engineer: Labs 03, 04, 07, 10, and 12
- AI and agent-security reader: Labs 06, 11, and 13
- Research or publication reader: Publications and Research
- Looking for authoritative references: Additional Resources
- A lab failed: Lab README → Troubleshooting Guide → repository issue
Some topics evolve independently of this repository or require deeper experimentation than fits within the Docker Security Guide. These companion repositories provide verified implementations, extended experiments, and specialized documentation.
| Project | Description |
|---|---|
| Docker Sandbox DevOps | Dedicated companion repository for Docker Sandboxes, AI coding-agent isolation, Kubernetes debugging, and DevOps toolkit experiments. |
Each lab has its own README with prerequisites, detailed steps, validation, expected results, and cleanup instructions. The root README intentionally provides a concise catalog so lab-specific documentation remains the source of truth.
Run Docker Bench Security, interpret CIS-aligned findings, identify dangerous configurations, and review practical remediations.
Estimated time: 30–45 minutes
Compare insecure and hardened configurations using capability controls, read-only filesystems, tmpfs, non-root execution, and no-new-privileges.
Estimated time: 45–60 minutes
Scan images with Trivy, generate SBOMs with Syft, analyze them with Grype, and enforce vulnerability policy with OPA.
Estimated time: 60–90 minutes
Sign and verify images with Cosign, examine content trust, manage signing keys, and enforce image-signing policy.
Estimated time: 45–60 minutes
Understand Linux syscalls, examine Docker's default seccomp behavior, generate restrictive profiles, and validate them without breaking workloads.
Estimated time: 90–120 minutes
Harden containerized ML inference with resource controls, input validation, monitoring, and Kubernetes security settings.
Estimated time: 60–90 minutes
Generate and compare SBOMs, scan them for vulnerabilities, and integrate supply-chain checks into GitHub Actions and Azure Pipelines.
Estimated time: 45–60 minutes
Practice network isolation, multi-tier segmentation, internal networks, TLS encryption, and common network-misconfiguration remediation.
Estimated time: 18–22 minutes
Explore Docker socket escape, privileged containers, CAP_SYS_ADMIN, host mounts, and /proc or /sys exposure, then apply Falco, Kyverno, and audit-script defenses.
Run offensive scenarios only in an isolated disposable environment. Do not use a production host.
Estimated time: 2–2.5 hours
Study secret leakage anti-patterns, Docker Swarm secrets, Vault integration, BuildKit secret mounts, repository scanning, and audit/compliance evidence.
Scenarios:
- Secret-management anti-patterns
- Docker Swarm secrets
- HashiCorp Vault integration
- BuildKit secrets
- Secret scanning
- Audit and compliance
Estimated time: approximately 90 minutes
Build an AutoGen-based agent that uses GPT-3.5-turbo and a secured MCP server to inspect logs, restart containers, update resources, and escalate unsafe or uncertain remediation decisions.
The security pipeline includes HMAC authentication, Redis-backed rate limiting, input validation, audit logging, non-root execution, read-only filesystems, dropped capabilities, and resource limits.
Scenarios: OOM remediation, crash escalation, exit-code retry logic, and health-check recovery.
Estimated time: 60–90 minutes
Build a vendor-neutral trust-control architecture using hardened images, Kyverno admission policies, Cosign, SBOM and provenance attestations, phased enforcement, break-glass controls, and fleet drift analysis.
Experiments:
- Drift observation
- Trust and provenance verification
- Admission enforcement
- Supply-chain gates
- Runtime failure modes
Estimated time: 90–120 minutes
Test zero-width Unicode instruction injection and malicious agent hooks against controlled projects, compare Claude Code and Gemini CLI behavior, and validate Docker Sandboxes as an infrastructure-level defense.
The lab documents two independent defenses:
- Agent-layer detection and refusal
- Sandbox-level filesystem isolation
Estimated time: follow the lab README; execution time varies by agent and sandbox environment
Common requirements:
- Docker Engine or Docker Desktop
- Docker Compose v2
- Linux, macOS, or Windows with WSL2
- Basic Docker and command-line knowledge
Some advanced labs additionally require tools such as kubectl, kind, helm, cosign, syft, grype, jq, Python, an OpenAI API key, or Docker Sandboxes. Always check the selected lab's README before starting.
git clone https://github.com/opscart/docker-security-practical-guide.git
cd docker-security-practical-guide
cd labs/01-docker-bench-security
cat README.md
./run-audit.shStart with Labs 01–06, then continue according to your goals. Each lab remains self-contained, so you can pause or skip topics that are not relevant to your environment.
Select labs by threat model:
- Labs 03, 04, 07, and 12 for vulnerability and supply-chain controls
- Labs 05, 08, and 09 for runtime and isolation controls
- Lab 10 for secrets management
- Labs 06, 11, and 13 for AI-related container security
Use Lab 01 for baseline checks, Labs 03 and 07 for vulnerability and SBOM evidence, Lab 09 for runtime-risk review, Lab 10 for secrets evidence, and Lab 12 for admission and trust-governance controls.
Focus on reusable scripts, CI/CD examples, policies, runtime controls, and migration patterns. Adapt them to your platform only after reviewing each lab's assumptions and safety notes.
Each lab is self-contained and may include:
- A lab-specific
README.md - Setup, execution, validation, and cleanup scripts
- Dockerfiles or Docker Compose configurations
- Kubernetes manifests and policy definitions
- Vulnerable and hardened examples
- Captured experiment evidence
- CI/CD configurations where relevant
cd labs/XX-lab-name
cat README.md
# Run only the commands documented by that lab.
# Cleanup commands also vary by lab.Foundations
Labs 01–06
|
+--> Supply chain and network security: Labs 07–08
|
+--> Runtime escape and defense: Lab 09
|
+--> Production security and remediation: Labs 10–11
|
+--> Container trust governance: Lab 12
|
+--> AI context security: Lab 13
Estimated total: approximately 14–17 hours, excluding optional extensions, environment setup, repeated experiments, and agent-dependent Lab 13 testing.
Docker Bench Security, Trivy, Syft, Grype, Cosign, OPA, Kyverno, Falco, Vault, GitLeaks, OpenSSL, Docker Scout, kind, Kubernetes, Redis, Flask, AutoGen, Claude Code, Gemini CLI, and Docker Sandboxes.
Docker Engine, Docker Compose, Linux capabilities, seccomp, user namespaces, read-only filesystems, Docker networking, TLS, CI/CD security gates, SBOMs, provenance, admission control, secrets management, AI tool isolation, and context-poisoning defense.
- Use minimal, maintained base images
- Pin versions or digests where reproducibility matters
- Scan images and generate SBOMs
- Sign and verify release images
- Enforce trusted origin, signature, provenance, and vulnerability policy
- Maintain break-glass procedures with auditability
- Run as a non-root user
- Drop unnecessary capabilities
- Use read-only filesystems and controlled writable mounts
- Apply seccomp and other supported Linux Security Modules
- Set CPU, memory, and PID limits
- Never expose the Docker socket to untrusted workloads
- Use dedicated networks instead of the default bridge
- Segment application tiers
- Restrict unnecessary ingress and egress
- Isolate sensitive services with internal networks
- Encrypt service traffic when required
- Generate SBOMs for release artifacts
- Scan continuously rather than only once
- Define severity and exception policy
- Preserve evidence for audits and incident response
- Track dependency and base-image changes
- Never commit production credentials
- Avoid hardcoded secrets and build arguments
- Prefer purpose-built secret stores or controlled secret mounts
- Rotate and scope credentials
- Scan repositories and audit access
- Monitor runtime behavior
- Record security-sensitive actions
- Maintain tested cleanup and incident-response procedures
- Separate automated remediation from high-risk actions
- Require human approval where confidence or blast radius is unacceptable
See Lab 08 architecture diagrams for multi-tier segmentation and encrypted communication patterns.
See Lab 12 architecture for the Supply Chain → Trust → Enforcement control loop, and Lab 07 for SBOM workflows.
Contributions are welcome:
- Fork the repository
- Create a focused branch
- Test the affected lab
- Update its documentation
- Submit a pull request
- Additional defensive scenarios
- Cloud-platform implementations
- CI/CD and policy integrations
- Compatibility testing on Linux, macOS, and Windows
- Corrections, reproducibility improvements, and clearer validation
Detailed external references are maintained in docs/additional-resources.md.
Start with docs/troubleshooting.md, then use the selected lab's README or lab-local troubleshooting guide.
docker version
docker compose versionFor script permission errors:
chmod +x script-name.shDo not use generic cleanup commands across all labs. Use the cleanup procedure documented by the selected lab.
- Lab 01: Security Auditing
- Lab 02: Secure Configurations
- Lab 03: Vulnerability Scanning Pipeline
- Lab 04: Image Signing and Verification
- Lab 05: Custom Seccomp Profiles
- Lab 06: AI Model Security
- Lab 07: Supply Chain Security with SBOM
- Lab 08: Docker Network Security
- Lab 09: Docker Runtime Escape
- Lab 10: Docker Secrets Management
- Lab 11: Docker MCP Gateway
- Lab 12: Container Trust Control Plane
- Lab 13: AI Context Poisoning Detection and Defense
Docker Sandboxes is evolving rapidly. To keep this repository focused on core Docker security while allowing rapid experimentation, advanced Docker Sandbox content is maintained in a dedicated companion repository.
Topics include:
- Docker Sandbox architecture
- microVM isolation
- AI coding agent security
- network policy experiments
- filesystem isolation
- credential isolation
- Kubernetes debugging inside Sandboxes
- custom DevOps toolkit
- verified engineering findings
Repository:
https://github.com/opscart/docker-sandbox-devops
MIT License. See LICENSE.
Thanks to the Docker, CIS, OWASP, Anchore, Sigstore, CNCF, and broader open-source security communities whose tools, standards, and documentation support these labs.
- Author: Shamsher Khan
- GitHub: @opscart
- Website: OpsCart
- Issues: Report a problem or propose an improvement
- Discussions: GitHub Discussions
- Senior DevOps Engineer
- IEEE Senior Member
- 15+ years of IT experience
- 10+ years of cloud and DevOps specialization
- Published technical author and CNCF contributor
Star the repository, share a lab with your team, report reproducibility issues, or contribute a focused improvement.
Watch the repository and follow @opscart for updates.