SebastianGruza commented on issue #3211: URL: https://github.com/apache/hugegraph/issues/3211#issuecomment-5748982387
I'd like to take this, but before writing code I want to agree on the shape, since it touches all three images at once and existing data on PVCs. What I checked in the repo and in the `:latest` images of 2026-09-18: - None of the three Dockerfiles declares `USER`; each has a `VOLUME` on the whole install directory (`/hugegraph-server`, `/hugegraph-pd`, `/hugegraph-store`), so data, logs, `conf` and `bin/pid` are one root-owned tree; the entrypoint is `dumb-init` + `docker-entrypoint.sh`, `HEALTHCHECK` through curl. Hubble starts as root too. - What writes at runtime: all three start scripts write `bin/pid` and `logs/*` (including heap dumps via `-XX:HeapDumpPath=logs`, and `logs/gc.log` on the Store); Jetty unpacks into `/tmp`; the Server entrypoint appends to `conf/graphs/hugegraph.properties` and `conf/rest-server.properties` and creates an init marker; the PD and Store entrypoints write nothing (their config goes through `SPRING_APPLICATION_JSON`). Data: `pd_data`, `storage`, `rocksdb-data` under the install directory. - The #221 chart already has `podSecurityContext`/`securityContext` per component and mounts the PVC only at `dataPath`, so logs, `conf` and `bin` live in the image layer today. ### Proposal: two steps **Step 1, this PR: non-root.** A fixed UID/GID and user (`hugegraph`) in each Dockerfile, `chown` of the install directory, `USER` before `ENTRYPOINT`; `dumb-init` and `HEALTHCHECK` unchanged. Start scripts unchanged except one thing: the pid file out of `bin/` (question 2). CI: extend the existing image tests (`docker/test-compose.sh smoke`, `test-wait-storage.sh`) with an `id -u` check inside the container and a start under `--user`/`runAsNonRoot`. Upgrade note: data on existing volumes was written as root, one-time `chown`, and in the chart `fsGroup` plus an optional initContainer that does it for the operator. **Step 2, follow-up: `readOnlyRootFilesystem`.** Requires everything written to live on mounted volumes: `logs` and `/tmp` on `emptyDir`, the pid next to the logs, and the Server entrypoint rendering its config into a writable directory instead of editing `conf/` in place. A separate PR, since it changes the Server entrypoint and the chart templates. ### Validation I can do On a three-node k3s with the #221 chart: a namespace with `pod-security.kubernetes.io/enforce: restricted`, kubescape before and after, the full fault battery of 2026-09-16 and the readiness scenarios on the new images, plus an upgrade of an existing cluster whose data was written as root, through the initContainer. I'd build the images with `docker/bake.hcl` and overlay them on the cluster the way I tested #3221. ### Four questions 1. **UID.** I'd propose a fixed `1000:1000`: least friction with `fsGroup` and with provisioners like local-path, and the default user of many base images. The alternative is a dedicated high UID (e.g. 10001) that collides with nothing on the host. Do you have a preference or a requirement from the chart / scanner side? 2. **Pid file.** The scripts write `bin/pid`; in step 2 `bin/` becomes read-only. Move the pid to `logs/` now (one change in the three start/stop scripts, consistent with the tarball), or leave it in `bin/` for step 1 and move it together with read-only? 3. **Server config.** The entrypoint edits `conf/` in place. For step 1 it is enough that `conf/` belongs to the image user. For step 2 I'd render into `/hugegraph-server/run/conf` (emptyDir) and start the server from there. Any reason to do that right away? 4. **Existing data.** The upgrade note plus `fsGroup` in the chart cover volumes where `fsGroup` works; hostPath/local-path it does not. Do you want an optional initContainer (`chown -R` on `dataPath`, off by default) in the chart as part of this step, or the note only? After the answers I'll do the PR for the images and tests, and the chart diff under #221. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
