{"slug": "show-hn-hands-on-docker-security-labs-from-cis-checks-to-ai-context-poisoning", "title": "Show HN: Hands-on Docker security labs, from CIS checks to AI context poisoning", "summary": "OpsCart Labs released an open-source Docker security practical guide with 13 hands-on labs covering CIS-aligned auditing, container hardening, vulnerability management, image trust, seccomp, network security, runtime security, secrets management, AI workload security, and AI context-poisoning defenses. The repository includes reproducible scripts, configurations, policies, and captured experiment evidence, and is part of a collection of labs informed by production cloud and Kubernetes operations.", "body_md": "A hands-on Docker and container security guide built around reproducible labs, attack scenarios, defensive controls, and production-oriented validation.\n\nThe repository progresses from foundational Docker hardening to runtime escape analysis, secrets management, software supply-chain trust, AI-assisted remediation, and AI context-poisoning defenses.\n\n**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`/proc`\n\nor`/sys`\n\nexposure**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\n\nThis guide is part of [OpsCart Labs](https://opscart.com/labs/), a collection of open-source, hands-on labs informed by production cloud and Kubernetes operations.\n\n**Docker Security: A Practical Guide** — this repository\n\n- 13 labs covering Docker security from auditing through AI context defense\n- Reproducible scripts, configurations, policies, and captured experiment evidence\n- Status: active development\n\n[Certified Kubernetes Administrator Exam Prep](https://github.com/opscart/production-cka)\n\n- Hands-on CKA preparation labs\n- Automated validation and operational notes\n- Status: active development\n\n- Built from practical Docker, Kubernetes, cloud, and DevOps experience\n- Designed around reproducible scenarios rather than theory alone\n- Maintained in public Git repositories\n- Intended for engineers, security practitioners, auditors, and platform teams\n\nUse this section as the central entry point for the repository.\n\n| Area | Purpose |\n|---|---|\n|\n\n[Publications and Research](/opscart/docker-security-practical-guide/blob/master/docs/publications-and-research.md)[Additional Resources](/opscart/docker-security-practical-guide/blob/master/docs/additional-resources.md)[Setup Guide](/opscart/docker-security-practical-guide/blob/master/docs/setup-guide.md)[Troubleshooting Guide](/opscart/docker-security-practical-guide/blob/master/docs/troubleshooting.md)[Repository Issues](https://github.com/opscart/docker-security-practical-guide/issues)**New to the repository:**[Setup Guide](/opscart/docker-security-practical-guide/blob/master/docs/setup-guide.md)→[Lab Catalog](#lab-catalog)→ Lab 01**Docker or container security practitioner:**[Lab Catalog](#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](/opscart/docker-security-practical-guide/blob/master/docs/publications-and-research.md)** Looking for authoritative references:**[Additional Resources](/opscart/docker-security-practical-guide/blob/master/docs/additional-resources.md)** A lab failed:**Lab README →[Troubleshooting Guide](/opscart/docker-security-practical-guide/blob/master/docs/troubleshooting.md)→ repository issue\n\nSome 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.\n\n| Project | Description |\n|---|---|\n|\n\nEach 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.\n\nRun Docker Bench Security, interpret CIS-aligned findings, identify dangerous configurations, and review practical remediations.\n\n**Estimated time:** 30–45 minutes\n\nCompare insecure and hardened configurations using capability controls, read-only filesystems, `tmpfs`\n\n, non-root execution, and `no-new-privileges`\n\n.\n\n**Estimated time:** 45–60 minutes\n\nScan images with Trivy, generate SBOMs with Syft, analyze them with Grype, and enforce vulnerability policy with OPA.\n\n**Estimated time:** 60–90 minutes\n\nSign and verify images with Cosign, examine content trust, manage signing keys, and enforce image-signing policy.\n\n**Estimated time:** 45–60 minutes\n\nUnderstand Linux syscalls, examine Docker's default seccomp behavior, generate restrictive profiles, and validate them without breaking workloads.\n\n**Estimated time:** 90–120 minutes\n\nHarden containerized ML inference with resource controls, input validation, monitoring, and Kubernetes security settings.\n\n**Estimated time:** 60–90 minutes\n\nGenerate and compare SBOMs, scan them for vulnerabilities, and integrate supply-chain checks into GitHub Actions and Azure Pipelines.\n\n**Estimated time:** 45–60 minutes\n\nPractice network isolation, multi-tier segmentation, internal networks, TLS encryption, and common network-misconfiguration remediation.\n\n**Estimated time:** 18–22 minutes\n\nExplore Docker socket escape, privileged containers, `CAP_SYS_ADMIN`\n\n, host mounts, and `/proc`\n\nor `/sys`\n\nexposure, then apply Falco, Kyverno, and audit-script defenses.\n\nRun offensive scenarios only in an isolated disposable environment. Do not use a production host.\n\n**Estimated time:** 2–2.5 hours\n\nStudy secret leakage anti-patterns, Docker Swarm secrets, Vault integration, BuildKit secret mounts, repository scanning, and audit/compliance evidence.\n\n**Scenarios:**\n\n- Secret-management anti-patterns\n- Docker Swarm secrets\n- HashiCorp Vault integration\n- BuildKit secrets\n- Secret scanning\n- Audit and compliance\n\n**Estimated time:** approximately 90 minutes\n\nBuild 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.\n\nThe security pipeline includes HMAC authentication, Redis-backed rate limiting, input validation, audit logging, non-root execution, read-only filesystems, dropped capabilities, and resource limits.\n\n**Scenarios:** OOM remediation, crash escalation, exit-code retry logic, and health-check recovery.\n\n**Estimated time:** 60–90 minutes\n\nBuild 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.\n\n**Experiments:**\n\n- Drift observation\n- Trust and provenance verification\n- Admission enforcement\n- Supply-chain gates\n- Runtime failure modes\n\n**Estimated time:** 90–120 minutes\n\nTest 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.\n\nThe lab documents two independent defenses:\n\n- Agent-layer detection and refusal\n- Sandbox-level filesystem isolation\n\n**Estimated time:** follow the lab README; execution time varies by agent and sandbox environment\n\nCommon requirements:\n\n- Docker Engine or Docker Desktop\n- Docker Compose v2\n- Linux, macOS, or Windows with WSL2\n- Basic Docker and command-line knowledge\n\nSome advanced labs additionally require tools such as `kubectl`\n\n, `kind`\n\n, `helm`\n\n, `cosign`\n\n, `syft`\n\n, `grype`\n\n, `jq`\n\n, Python, an OpenAI API key, or Docker Sandboxes. Always check the selected lab's README before starting.\n\n```\ngit clone https://github.com/opscart/docker-security-practical-guide.git\ncd docker-security-practical-guide\n\ncd labs/01-docker-bench-security\ncat README.md\n./run-audit.sh\n```\n\nStart 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.\n\nSelect labs by threat model:\n\n- Labs 03, 04, 07, and 12 for vulnerability and supply-chain controls\n- Labs 05, 08, and 09 for runtime and isolation controls\n- Lab 10 for secrets management\n- Labs 06, 11, and 13 for AI-related container security\n\nUse 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.\n\nFocus 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.\n\nEach lab is self-contained and may include:\n\n- A lab-specific\n`README.md`\n\n- Setup, execution, validation, and cleanup scripts\n- Dockerfiles or Docker Compose configurations\n- Kubernetes manifests and policy definitions\n- Vulnerable and hardened examples\n- Captured experiment evidence\n- CI/CD configurations where relevant\n\n```\ncd labs/XX-lab-name\ncat README.md\n\n# Run only the commands documented by that lab.\n# Cleanup commands also vary by lab.\nphp\nFoundations\nLabs 01–06\n    |\n    +--> Supply chain and network security: Labs 07–08\n    |\n    +--> Runtime escape and defense: Lab 09\n    |\n    +--> Production security and remediation: Labs 10–11\n    |\n    +--> Container trust governance: Lab 12\n    |\n    +--> AI context security: Lab 13\n```\n\n**Estimated total:** approximately 14–17 hours, excluding optional extensions, environment setup, repeated experiments, and agent-dependent Lab 13 testing.\n\nDocker 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.\n\nDocker 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.\n\n- Use minimal, maintained base images\n- Pin versions or digests where reproducibility matters\n- Scan images and generate SBOMs\n- Sign and verify release images\n- Enforce trusted origin, signature, provenance, and vulnerability policy\n- Maintain break-glass procedures with auditability\n\n- Run as a non-root user\n- Drop unnecessary capabilities\n- Use read-only filesystems and controlled writable mounts\n- Apply seccomp and other supported Linux Security Modules\n- Set CPU, memory, and PID limits\n- Never expose the Docker socket to untrusted workloads\n\n- Use dedicated networks instead of the default bridge\n- Segment application tiers\n- Restrict unnecessary ingress and egress\n- Isolate sensitive services with internal networks\n- Encrypt service traffic when required\n\n- Generate SBOMs for release artifacts\n- Scan continuously rather than only once\n- Define severity and exception policy\n- Preserve evidence for audits and incident response\n- Track dependency and base-image changes\n\n- Never commit production credentials\n- Avoid hardcoded secrets and build arguments\n- Prefer purpose-built secret stores or controlled secret mounts\n- Rotate and scope credentials\n- Scan repositories and audit access\n\n- Monitor runtime behavior\n- Record security-sensitive actions\n- Maintain tested cleanup and incident-response procedures\n- Separate automated remediation from high-risk actions\n- Require human approval where confidence or blast radius is unacceptable\n\nSee [Lab 08 architecture diagrams](/opscart/docker-security-practical-guide/blob/master/labs/08-network-security/docs/ARCHITECTURE_DIAGRAMS.md) for multi-tier segmentation and encrypted communication patterns.\n\nSee [Lab 12 architecture](/opscart/docker-security-practical-guide/blob/master/labs/12-docker-hardened-images/docs/architecture.md) for the Supply Chain → Trust → Enforcement control loop, and [Lab 07](/opscart/docker-security-practical-guide/blob/master/labs/07-supply-chain-sbom) for SBOM workflows.\n\nContributions are welcome:\n\n- Fork the repository\n- Create a focused branch\n- Test the affected lab\n- Update its documentation\n- Submit a pull request\n\n- Additional defensive scenarios\n- Cloud-platform implementations\n- CI/CD and policy integrations\n- Compatibility testing on Linux, macOS, and Windows\n- Corrections, reproducibility improvements, and clearer validation\n\nDetailed external references are maintained in [docs/additional-resources.md](/opscart/docker-security-practical-guide/blob/master/docs/additional-resources.md).\n\nStart with [docs/troubleshooting.md](/opscart/docker-security-practical-guide/blob/master/docs/troubleshooting.md), then use the selected lab's README or lab-local troubleshooting guide.\n\n```\ndocker version\ndocker compose version\n```\n\nFor script permission errors:\n\n```\nchmod +x script-name.sh\n```\n\nDo not use generic cleanup commands across all labs. Use the cleanup procedure documented by the selected lab.\n\n- Lab 01: Security Auditing\n- Lab 02: Secure Configurations\n- Lab 03: Vulnerability Scanning Pipeline\n- Lab 04: Image Signing and Verification\n- Lab 05: Custom Seccomp Profiles\n- Lab 06: AI Model Security\n- Lab 07: Supply Chain Security with SBOM\n- Lab 08: Docker Network Security\n- Lab 09: Docker Runtime Escape\n- Lab 10: Docker Secrets Management\n- Lab 11: Docker MCP Gateway\n- Lab 12: Container Trust Control Plane\n- Lab 13: AI Context Poisoning Detection and Defense\n\nDocker 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.\n\nTopics include:\n\n- Docker Sandbox architecture\n- microVM isolation\n- AI coding agent security\n- network policy experiments\n- filesystem isolation\n- credential isolation\n- Kubernetes debugging inside Sandboxes\n- custom DevOps toolkit\n- verified engineering findings\n\nRepository:\n\n[https://github.com/opscart/docker-sandbox-devops](https://github.com/opscart/docker-sandbox-devops)\n\nMIT License. See [LICENSE](/opscart/docker-security-practical-guide/blob/master/LICENSE).\n\nThanks to the Docker, CIS, OWASP, Anchore, Sigstore, CNCF, and broader open-source security communities whose tools, standards, and documentation support these labs.\n\n**Author:** Shamsher Khan**GitHub:**[@opscart](https://github.com/opscart)** Website:**[OpsCart](https://opscart.com)** Issues:**[Report a problem or propose an improvement](https://github.com/opscart/docker-security-practical-guide/issues)** Discussions:**[GitHub Discussions](https://github.com/opscart/docker-security-practical-guide/discussions)\n\n- Senior DevOps Engineer\n- IEEE Senior Member\n- 15+ years of IT experience\n- 10+ years of cloud and DevOps specialization\n- Published technical author and CNCF contributor\n\nStar the repository, share a lab with your team, report reproducibility issues, or contribute a focused improvement.\n\nWatch the repository and follow [@opscart](https://github.com/opscart) for updates.", "url": "https://wpnews.pro/news/show-hn-hands-on-docker-security-labs-from-cis-checks-to-ai-context-poisoning", "canonical_source": "https://github.com/opscart/docker-security-practical-guide", "published_at": "2026-08-26 03:56:32+00:00", "updated_at": "2026-08-26 04:16:09.741361+00:00", "lang": "en", "topics": ["ai-safety", "ai-ethics", "ai-infrastructure", "ai-tools"], "entities": ["OpsCart Labs", "Docker Bench Security", "Trivy", "Syft", "Grype", "Cosign", "Vault", "Kyverno"], "alternates": {"html": "https://wpnews.pro/news/show-hn-hands-on-docker-security-labs-from-cis-checks-to-ai-context-poisoning", "markdown": "https://wpnews.pro/news/show-hn-hands-on-docker-security-labs-from-cis-checks-to-ai-context-poisoning.md", "text": "https://wpnews.pro/news/show-hn-hands-on-docker-security-labs-from-cis-checks-to-ai-context-poisoning.txt", "jsonld": "https://wpnews.pro/news/show-hn-hands-on-docker-security-labs-from-cis-checks-to-ai-context-poisoning.jsonld"}}