Run the release image as uid 65532

[schronck]

The runtime image had no USER, so the container ran as uid 0. The binary never needed it: it binds 8080 and 9000, both above 1024, and writes only under its data directory.

The image

Base moves to gcr.io/distroless/cc-debian12:nonroot. I read the image config from the registry rather than trusting the tag name:

User:       '65532'
WorkingDir: '/home/nonroot'

USER 65532:65532 is also stated explicitly in the Dockerfile. The base already sets it, but stating it keeps the runtime identity visible in the file and surviving a base-image change.

One thing the issue did not mention, and it would have broken docker run

DECPM_DIR defaulted to /. It is the root dir, and the app writes $DECPM_DIR/data — so the default put the database at /data, which uid 65532 cannot create. Switching the base without touching this would have left the image failing on its first write for anyone running it directly.

It now defaults to /home/nonroot, which the nonroot user owns. Deployments are unaffected either way: the guide mounts a volume and passes -d /app, and development/docker-compose.yml builds from a different Dockerfile and sets DECPM_DIR: /app itself.

The deployment guide

Pod-level:

securityContext:
  runAsNonRoot: true
  runAsUser: 65532
  runAsGroup: 65532
  fsGroup: 65532

Container-level: allowPrivilegeEscalation: false and capabilities: drop: ["ALL"].

Two details worth a reviewer's eye:

• The init container matters. busybox defaults to root, and with runAsNonRoot: true at pod level the pod refuses to start unless that container also runs nonroot. It inherits the pod context, and fsGroup is what then lets both it and the app write to the mounted PVC. Without fsGroup this change breaks the deploy.
• readOnlyRootFilesystem is left commented, not set. It should hold — every /tmp and tempfile use I found is test code or the gen-types binary, not the server — but I cannot prove it without a live deploy, and a dependency writing to /tmp would surface only at runtime. The guide says to enable it and watch one restart.

Also documented: the image runs as 65532, and the workaround for v1.6.2 and earlier, which is to set runAsUser: 65532 plus the same fsGroup on the existing image.

Verification

No docker in this environment, so I could not build the image. What I did check:

• The nonroot image config, pulled from gcr.io (above), confirming uid and home.
• The guide's Deployment manifest parses as YAML, and the resulting security contexts and command are the intended ones.

The image itself is unverified by a build. The remaining risk is the base-image swap, which CI will exercise on this PR.

Follow-up the issue asks for and this does not do

Cut a new release so the rebuilt image picks up the current Debian 12 package versions.

That is a tag push, not a code change, so it stays with whoever cuts releases. The OS-level CVEs the scanners report come from the base image and clear on a rebuild.

Closes #372

[Copilot]

Pull request overview

This PR hardens the runtime container by running the release image as a non-root user (uid/gid 65532) and updates the Kubernetes deployment documentation to match the tightened security posture and filesystem ownership requirements.

Changes:

• Switch the runtime base image to gcr.io/distroless/cc-debian12:nonroot and explicitly set USER 65532:65532.
• Change the runtime default DECPM_DIR to /home/nonroot so the non-root process can create its data/ directory by default.
• Update docs/DEPLOYMENT_GUIDE.md to add pod/container securityContext settings (runAsNonRoot, runAsUser, fsGroup, drop caps, etc.) and document the init-container interaction.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
docs/DEPLOYMENT_GUIDE.md	Documents non-root runtime behavior and updates the Deployment example to use pod/container security contexts appropriate for uid 65532.
Dockerfile	Moves the runtime image to distroless :nonroot, sets USER 65532:65532, and updates DECPM_DIR defaults for non-root writes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.