Short version for the impatient: your container is probably running as root, it probably has more Linux capabilities than it needs, and its filesystem is probably writable. Three small changes fix most of that. If you want to know why I care, read on.<\/p>\n
I got a scare about eight months ago. Not a breach, thankfully. A client asked for a security questionnaire to be filled in and one of the questions was “do application containers run as a non-root user?” I said yes, because obviously they did, and then I went and checked, and they did not. Every service. Every image. Root all the way down, for about two years, because nobody had ever typed That’s the annoying thing about container security. Almost none of it is hard. It’s just invisible by default. Docker will happily run whatever you give it with the most permissive settings available and never mention that there was a choice.<\/p>\n So here’s the checklist I run now, in the order I run it.<\/p>\n The mental model a lot of us start with is “container equals tiny VM”. It isn’t. Your container shares the host kernel. A VM has a hypervisor between the guest and the hardware. A container has namespaces and cgroups, which are kernel features doing bookkeeping, not isolation in the hardware sense.<\/p>\n Practically: a kernel bug that lets a process escalate inside the container can put that process on the host. That’s a much shorter path than escaping a hypervisor. It doesn’t mean containers are unsafe. It means the defence has to be “this process can’t do much even if it gets out”, not “this process can’t get out”.<\/p>\n Everything below follows from that one idea.<\/p>\n By default, the process inside your container runs as uid 0. If you’ve bind-mounted a host directory into that container, uid 0 inside is uid 0 outside. Files it writes are owned by root on your host. That’s not theoretical; I’ve spent real time running The fix is boring:<\/p>\n The official Node images already ship a Order matters. Anything that needs root, like installing system packages, has to happen before the If you want the stronger version of this, Docker supports rootless mode<\/a>, where the daemon itself runs as an unprivileged user. I run it on my own machine. On shared build servers it’s been more of a fight, mostly around networking and storage drivers, so I won’t pretend it’s free.<\/p>\n Linux capabilities split root’s powers into pieces: bind to low ports, change file ownership, load kernel modules, and so on. Docker grants a default set to every container. Your Express app does not need Start from nothing:<\/p>\n Then run your test suite and see what explodes. Usually nothing does. If you need port 80 directly, you’ll want If your app doesn’t write to disk, don’t let it. If it does write, let it write to exactly one place.<\/p>\n This one catches things. An attacker who lands remote code execution but can’t drop a file anywhere persistent is having a much worse day. It also surfaces sloppiness in your own code, because you find out what’s quietly scribbling into the image at runtime.<\/p>\n Expect a couple of surprises the first time. Some frameworks cache compiled templates or config into the app directory on boot. I hit this with a PHP service that wanted to write its container cache at runtime, and the fix was to warm the cache at build time instead, which was better anyway. I wrote about the queue side of that same app in my Laravel Horizon setup<\/a>.<\/p>\n This is the mistake I see most in other people’s repos, and it’s the one with the worst blast radius.<\/p>\n Wrong:<\/p>\n That token is now baked into a layer. Deleting the file in a later layer doesn’t remove it. Anyone who can pull the image can run Right, using BuildKit’s secret mounts<\/a>:<\/p>\n The secret is available during that one command and never written to a layer. Runtime secrets are a separate problem: keep them out of Plenty of CI tools and monitoring agents ask for it. Sometimes there’s no alternative and you accept the risk knowingly, on a box that does nothing else. What you shouldn’t do is mount it into an app container next to your customer data because a tutorial said to.<\/p>\n The OWASP Docker Security Cheat Sheet<\/a> is good on this and worth twenty minutes if you want the fuller list.<\/p>\n Scanning gets all the attention because vendors sell scanners. Pinning matters more and costs nothing.<\/p>\n Yes, it’s ugly. Yes, you need Renovate or Dependabot to bump it. That’s the point: upgrades become a reviewed change instead of something that happens to you at 3am.<\/p>\n Then scan. Trivy<\/a> is what I use, mostly because it runs in CI without an account:<\/p>\n One warning from experience: don’t gate your pipeline on zero findings on day one. You’ll get four hundred CVEs in your base image, half of them unreachable from your code, and within a week someone adds Smaller images help here more than any scanner does. A multi-stage build that ships only the compiled binary and its runtime has almost no packages to have CVEs about. That’s a real chunk of why I moved some services onto leaner runtimes, which I got into in a year of running Bun in production<\/a>.<\/p>\n Pick your busiest service. Open its Dockerfile and its compose file. Add That’s an hour of work and it removes most of the easy paths off a compromised container. Digest pinning and scanning can wait until next week; they’re maintenance, and maintenance without the basics in place is just paperwork.<\/p>\nUSER<\/code> into a Dockerfile and Docker doesn’t nag you about it.<\/p>\nContainers aren’t a security boundary, and I wish people said that louder<\/h2>\n
Running as root is the default and it’s a two-line fix<\/h2>\n
sudo chown<\/code> on directories a container mangled.<\/p>\nFROM node:22-slim\n\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm ci --omit=dev\nCOPY . .\n\nUSER node\nCMD ["node", "server.js"]\n<\/code><\/pre>\nnode<\/code> user, so you don’t even have to create one. If your base image doesn’t, add it yourself:<\/p>\nRUN groupadd --system --gid 1001 app \\\n && useradd --system --uid 1001 --gid app app\nUSER app\n<\/code><\/pre>\nUSER<\/code> line. That trips people up and then they give up and delete the line. Don’t. Just move it down.<\/p>\nDrop every capability, add back what breaks<\/h2>\n
CAP_CHOWN<\/code>.<\/p>\nservices:\n api:\n image: ghcr.io\/me\/api:sha-9f2c1ab\n cap_drop:\n - ALL\n security_opt:\n - no-new-privileges:true\n<\/code><\/pre>\nNET_BIND_SERVICE<\/code> back, though I’d rather listen on 8080 and let the reverse proxy handle 80.<\/p>\nno-new-privileges<\/code> is the one people skip. It stops a process inside the container from gaining privileges through setuid binaries. There’s basically no downside for an application container, and it’s one line.<\/p>\nMake the filesystem read-only<\/h2>\n
services:\n api:\n read_only: true\n tmpfs:\n - \/tmp\n volumes:\n - uploads:\/var\/app\/uploads\n<\/code><\/pre>\nBuild secrets do not belong in ARG or ENV<\/h2>\n
ARG NPM_TOKEN\nRUN echo "\/\/registry.npmjs.org\/:_authToken=${NPM_TOKEN}" > .npmrc \\\n && npm ci\n<\/code><\/pre>\ndocker history<\/code> or just unpack the tarball and read it.<\/p>\nRUN --mount=type=secret,id=npmrc,target=\/root\/.npmrc \\\n npm ci --omit=dev\n<\/code><\/pre>\ndocker build --secret id=npmrc,src=$HOME\/.npmrc -t api:latest .\n<\/code><\/pre>\nENV<\/code> too, because docker inspect<\/code> prints environment variables in full, and so do a lot of logging agents.<\/p>\nNever mount the Docker socket into a container<\/h2>\n
-v \/var\/run\/docker.sock:\/var\/run\/docker.sock<\/code> is root on the host. Not “close to root”. Root. A process with the socket can start a new container with the host filesystem mounted at \/host<\/code> and do whatever it wants.<\/p>\nPin by digest, then scan<\/h2>\n
FROM node:22-slim<\/code> is a moving target. The image behind that tag changes. Your reproducible build isn’t reproducible, and “it worked in CI last week” stops being evidence of anything.<\/p>\nFROM node:22-slim@sha256:c0e8f2ff2b3f4d7dc1c6ea0d9e0d3f5b1a5f2f0d3d9b8e1a4c7d2e5f8a1b4c7d\n<\/code><\/pre>\ntrivy image --severity HIGH,CRITICAL --exit-code 1 api:latest\n<\/code><\/pre>\n--exit-code 0<\/code> and nobody looks again. Start by failing on CRITICAL only, get that to zero, then tighten.<\/p>\nWhat I’d actually do this week<\/h2>\n
USER<\/code>, add cap_drop: ALL<\/code>, add no-new-privileges<\/code>, add read_only: true<\/code> with a tmpfs for \/tmp<\/code>. Run the test suite. Fix what breaks, which will be less than you think.<\/p>\n