Security

docker network rm -f and docker context rm -f share a flag name and do different things. docker network rm --help says its -f means “Do not error if the network does not exist”: a network still attached to a running container survives it regardless. docker context rm --help says its own -f means “Force the removal of a context in use”: on a context, -f genuinely forces removal even while it’s the active one. Both commands describe their own behavior accurately. The trap is assuming -f means the same thing everywhere because it’s the same letter, and skipping the one --help you actually needed to read. docker-destructive-guardrails, the skill this closing post covers, exists for exactly this kind of inconsistency: the places where “it looked like the other command” is how damage happens. ...

One command, sbx run claude ., and Claude gets a complete, disposable place to work: its own filesystem, its own network, its own Docker daemon, built from the current directory in a few seconds, instead of running directly on your machine with your own shell, your own files, and your own network access. That’s Docker Sandboxes: a standalone sbx CLI that runs an AI coding agent inside an isolated microVM so a runaway command, a bad rm, or a prompt-injected instruction stays contained to a disposable environment instead of your actual laptop. See the Docker Sandboxes documentation for the full product picture; docker-sandboxes-lifecycle and docker-sandboxes-network-credentials, the two skills this post covers, are what make that sandbox practical to drive day to day: how isolated the agent’s workspace is, how you get back into a sandbox you left running, and exactly what it can reach on the network and authenticate with. ...

A registry token passed through ARG never shows up in docker run, never gets printed by the app, looks completely invisible. It’s still sitting in the image’s layer history, one docker history away from anyone who pulls it. That’s the exact mistake docker-build-strategies is written to intercept, and it’s one of several the Dockerfile & Build family of Docker Skills, covered here alongside docker-project-foundations, catches before the image ships. Part 1 introduced Docker Skills and the eleven skills it ships. The two skills in this post are deliberately scoped apart: docker-project-foundations handles the case where there’s no Docker setup at all yet, and steps aside once a project has a mature one that only needs minor edits; docker-build-strategies optimizes and hardens an existing Dockerfile, and steps aside when the actual need is that first-pass scaffold, or when the task is really about Compose wiring rather than image internals. Part 3 covers that Compose wiring skill next. ...

Run this from a container whose process is uid 0: services: hardened: image: alpine cap_drop: - ALL command: sh -c "touch /tmp/f && chown 2000:2000 /tmp/f && echo OK" docker compose run --rm hardened chown: /tmp/f: Operation not permitted Tip #29 listed which cap_add values pair with which workload. This is the part worth sitting with: cap_drop: ALL just took a privilege away from uid 0, not from some non-root user it was supposedly protecting against. ...

Compose makes secret delivery look settled. Declare a top-level secret, grant a service access to it, and the value appears under /run/secrets/. The interface is simple; the storage and delivery path behind it are not. Outside Swarm, a file-backed Compose secret is a bind mount. A secret sourced from the host environment follows a different path and, with current Compose versions, ends up in the container’s writable layer. Both appear under /run/secrets, but they leave different traces on the host and behave differently when someone runs docker commit. The path alone says nothing about whether the value lives in a tmpfs. ...