Allow UID/GID Overrides for Indexer Docker Image

[artntek]

@vchendrix said:

I had to build my own dataone-indexer image which I inherited from yours. I had to do this in order to use my own UID and GID. [...] IIRC it just couldn’t execute the scripts…

# Docker from that inherits dataone-indexer and changes user permissions
# to allow the container to run as a non-root user. This is important for security and best practices.
# The Dockerfile also includes a liveness probe and readiness probe to ensure that the container is running
# and ready to accept traffic. The liveness probe checks if the container is alive, while the readiness probe
ARG VERSION=3.1.3
ARG D1_UID=76553
ARG D1_GID=72528


FROM ghcr.io/dataoneorg/dataone-index-worker:${VERSION}

USER root

# Ensure the d1indexer group and user exist
ARG D1_UID
ARG D1_GID

# Ensure the d1indexer group and user exist
RUN groupmod -g ${D1_GID} d1indexer && \
    usermod -u ${D1_UID} -g ${D1_GID} d1indexer

# Change the ownership of the jar and sh files
RUN chown d1indexer:d1indexer dataone-index-worker-${TAG}-shaded.jar
RUN chown d1indexer:d1indexer entrypoint.sh
RUN chown d1indexer:d1indexer livenessprobe
RUN chown d1indexer:d1indexer readinessprobe

#Run Container as d1indexer
USER d1indexer

# Connect this image to a GitHub repository
LABEL org.opencontainers.image.source="https://github.com/ess-dive/essdive-appstack"

# Run the Worker process
CMD ["./entrypoint.sh"]

If we set securityContext.runAsUser and runAsGroup in the helm chart,

Kubernetes allows us to specify which user a container should run as using the securityContext.runAsUser and runAsGroup fields. However, this only changes the process UID/GID at runtime; it does not modify the user or group definitions inside the image.

If the specified UID/GID does not exist in the image, the process will run with that numeric UID/GID, but it may not have a username or home directory, and file permissions inside the container may not match up as expected.

In the current Dockerfile, we do this:

RUN groupadd -g 59997 d1indexer && useradd -u 59997 -g 59997 d1indexer \
    && touch ./livenessprobe && touch ./readinessprobe

[...]

# Change the ownership of the jar and sh files
RUN chown d1indexer dataone-index-worker-${TAG}-shaded.jar
RUN chown d1indexer entrypoint.sh
RUN chown d1indexer livenessprobe
RUN chown d1indexer readinessprobe

#Run Container as d1indexer
USER 59997:59997

• Look how others handle this, as a best practice (e.g. I specified 59997 for the busybox initContainer - which runs as root by default - and it worked ok)
• First thing to try might simply be doing a chmod 775 on the jar file and entrypoint script, and chmod 777 on the 2 probe files