Summary
The current openpi project does not specify a USER directive in Docker-based deployments, causing container processes to run as root. Community integrations that build on openpi inherit this pattern. This is flagged by container security scanners (Semgrep, Checkov CKV_DOCKER_8) and is a security anti-pattern.
Current behavior
When building a Docker image based on nvcr.io/nvidia/cuda:12.3.2-cudnn9-devel-ubuntu22.04 + openpi:
uv is installed to /root/.local/bin via curl -LsSf https://astral.sh/uv/install.sh | sh
PATH="/root/.local/bin:$PATH" hardcodes a root-only path
- No
USER directive → all container processes run as root
Desired behavior
Container process should run as a non-root user (e.g., appuser) while retaining full GPU / CUDA and JAX access.
Why this is blocked today
- uv installation path:
uv installs to /root/.local/bin by default. Switching to a non-root user requires reinstalling uv to a shared path (e.g., /usr/local/bin) or updating PATH.
- Model checkpoint directory:
/opt/pi-cache and checkpoint files are written as root during the build phase; need chown before the USER switch.
- JAX CUDA initialization: Uncertain whether JAX GPU initialization requires root privileges inside NVIDIA CUDA base images.
Proposed approach
# Install uv to a shared location accessible to non-root
RUN curl -LsSf https://astral.sh/uv/install.sh | env UV_INSTALL_DIR=/usr/local/bin sh
# After all setup steps:
RUN useradd -m -u 1000 appuser && \
chown -R appuser:appuser /opt/pi-cache /opt/openpi /opt/ml
USER appuser
Question: Is there a known blocker for non-root execution with nvcr.io/nvidia/cuda base images for JAX workloads? Does JAX GPU (CUDA) initialization require root, or can it run as a non-privileged user?
Security context
Running containers as root is considered a security anti-pattern, especially for:
- Open-source projects intended for research/production use
- Environments with Kubernetes/ECS runtime security policies (e.g.,
runAsNonRoot: true)
- Security reviews (e.g., AWS PCSR / AppSec) that flag
CKV_DOCKER_8 / SEC-001
Any guidance on the safest path to non-root execution would be greatly appreciated.
Summary
The current openpi project does not specify a
USERdirective in Docker-based deployments, causing container processes to run asroot. Community integrations that build on openpi inherit this pattern. This is flagged by container security scanners (Semgrep, Checkov CKV_DOCKER_8) and is a security anti-pattern.Current behavior
When building a Docker image based on
nvcr.io/nvidia/cuda:12.3.2-cudnn9-devel-ubuntu22.04+ openpi:uvis installed to/root/.local/binviacurl -LsSf https://astral.sh/uv/install.sh | shPATH="/root/.local/bin:$PATH"hardcodes a root-only pathUSERdirective → all container processes run asrootDesired behavior
Container process should run as a non-root user (e.g.,
appuser) while retaining full GPU / CUDA and JAX access.Why this is blocked today
uvinstalls to/root/.local/binby default. Switching to a non-root user requires reinstallinguvto a shared path (e.g.,/usr/local/bin) or updating PATH./opt/pi-cacheand checkpoint files are written as root during the build phase; needchownbefore theUSERswitch.Proposed approach
Question: Is there a known blocker for non-root execution with
nvcr.io/nvidia/cudabase images for JAX workloads? Does JAX GPU (CUDA) initialization require root, or can it run as a non-privileged user?Security context
Running containers as root is considered a security anti-pattern, especially for:
runAsNonRoot: true)CKV_DOCKER_8/SEC-001Any guidance on the safest path to non-root execution would be greatly appreciated.