How do I secure a container deployment?

How do I secure a container deployment?

Ship a current, minimal image, run the process as a non-root user, mount the root filesystem read-only, keep secrets out of layers, and scan the artifact in CI before you push it. Application rules (rate limits, bot detection, Shield) still belong in the handler. The container is the other half: it limits what an attacker can do after they get code execution.

Nothing here is 100% secure. Each control fails differently, so you stack them. A 2024 supply-chain incident is a useful historical check: the xz-utils backdoor (CVE-2024-3094) landed in liblzma and targeted sshd. Teams on rolling, inventoried images could confirm in minutes that they did not ship the tainted package and did not run sshd. Teams on stale fat images had a longer question.

Should containers run as non-root?

Yes. Docker runs as root unless you change it. If an attacker reaches child_process or a reverse shell, they inherit that user. Root inside the container can install miners, rewrite binaries, and (when a container-escape bug exists) start from a privileged uid on the host.

Set USER in the final stage. Distroless and Chainguard images already provide a nonroot user. Alpine does not; you create one.

This is a different control from rootless Docker or Podman on the host. USER limits what the process can do inside the container. Rootless runtimes limit what the container engine can do on the host. Use both if you run your own nodes. Managed platforms (Fly, Cloud Run, EKS) already constrain the host side; you still set USER.

Which base image is most secure?

The most secure image is the smallest current one that still runs your app. Size is a proxy for attack surface: fewer packages mean fewer CVEs and fewer binaries an attacker can exec. Compatibility is the constraint. Alpine uses musl; Node addons, some Go binaries, and DNS resolution have historically broken there. Distroless has no shell and no package manager. Wolfi (Chainguard) is a rolling glibc distro with an SBOM.

Use Node 22 (current LTS) on current Debian. Official Distroless Node images are Debian 13 (trixie). Do not copy older recipes that pin Node 20 on Debian 11 or 12.

A full node:22 Debian image is the worst default for production: hundreds of packages you never call. node:22-bookworm-slim / node:22-trixie-slim is acceptable for a build stage. Do not run the slim image as the final runtime if you can use Distroless or Wolfi.

1
FROM node:22 AS build
2
WORKDIR /app
3
COPY package.json package-lock.json ./
4
RUN npm ci --omit=dev
5
COPY . .
6

7
FROM gcr.io/distroless/nodejs22-debian13:nonroot
8
WORKDIR /app
9
COPY --from=build /app /app
10
USER nonroot
11
EXPOSE 3000
12
CMD ["index.js"]

Alpine needs the user created in the final stage:

1
FROM node:22-alpine
2
RUN addgroup -S app && adduser -S -G app nonroot
3
WORKDIR /app
4
COPY --from=build /app /app
5
USER nonroot
6
CMD ["node", "index.js"]

Why use a read-only filesystem?

A read-only root stops an attacker from writing a second binary, dropping a reverse shell, or replacing your entrypoint after they get execution. Test it locally:

1
docker run --rm --read-only node:22-alpine mkdir /tmp/pwn
2
# mkdir: can't create directory '/tmp/pwn': Read-only file system

If the process needs scratch space (Next.js cache, image uploads, session files), mount a tmpfs on those paths or move the data to object storage and a database. In Kubernetes set securityContext.readOnlyRootFilesystem: true and add an emptyDir with medium: Memory for /tmp.

Read-only does not stop an in-memory payload. It removes persistence and tooling. Combine it with non-root and a distroless image so there is no apk, apt, or /bin/sh to install that tooling anyway.

How do I scan images and secrets in CI?

Do not bake secrets into layers. Load them at runtime from the platform: Fly secrets, AWS Secrets Manager, GCP Secret Manager. Then scan the image you just built, because a .env copied by COPY . . will still be in a layer.

TruffleHog can scan a saved image. Gitleaks and GitHub push protection catch secrets in git before the image exists. osv-scanner fails the build on known dependency CVEs. Secret scanning in Next.js builds has the Next.js-specific artifact path (.vercel/output and NEXT_PUBLIC_ leakage).

1
- name: Save image
2
  run: docker save -o /tmp/app.tar my-app:latest
3
- name: Scan image for verified secrets
4
  run: >
5
    docker run --rm -v /tmp:/tmp trufflesecurity/trufflehog:latest
6
    docker --image file:///tmp/app.tar --fail --only-verified --no-update

Run the same Semgrep and Trunk rules locally and in CI. A pre-commit hook that CI does not enforce is optional.

How should I automate deployments?

Deploy from GitHub Actions (or the equivalent) with short-lived identity, not a long-lived cloud key in repository secrets.

• Workflow files are code. Review them.
• Environments hold per-stage secrets (prod, staging, region).
• Required checks and a human approval gate sit on production.
• GitHub's OIDC federation assumes an IAM role in AWS (or the Workload Identity equivalent) for the life of the job.
• Fly has an official deploy action and CLI. Deploying an Arcjet-protected app to Fly.io covers the ARCJET_KEY secret. Self-hosted PaaS setups such as Coolify need the same image rules plus a private admin network.

Container security checklist

Use this as a release gate. Skipping one row is not offset by passing another.