Start the container using a non-root user

[whg517]

Recently, I have been attempting to write the resource list for deploying Kubernetes based on Helm charts. However, during the deployment process, we encountered many compatibility issues related to cloud-native. Now, I will list some issues that I encountered when the rustfs container started the entrypoint using the root user:

In the practice of Kubernetes, to prevent container privilege escalation, it is generally recommended to deploy using non-root users and non-root file systems.

ref: security-context

      # pod security context
      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1000

        # container security context
        containers:
          securityContext:
          capabilities:
            drop:
            - ALL
          readOnlyRootFilesystem: false

When the rustfs image was built, directories /data and /logs belonging to the root user were already created, with the permission set to 0750. This will result in the inability to use these two directories properly after starting as a non-root user. Because 0750 is reserved for exclusive use by the system.

I noticed that in the startup script of the entrypoint, the uid:1000 user is used to ultimately start the rustfs process. Although this avoids some security risks, the container is still running as root.
My idea is that we should modify the entrypoint startup logic and run the entrypoint script in the Dockerfile without using root privileges at all.

FROM alpine:3.22

RUN <<EOF
groupadd -g 1001 --system rustfs
useradd \
    --no-log-init \
    --gid 1001 \
    --uid 1001 \
    --create-home \
    --home-dir /rustfs \
    rustfs
EOF

# Before exporting the image, switch the container user to a regular user.
USER rustfs

ENTRYPOINT ["/entrypoint.sh"]
CMD ["/usr/bin/rustfs"]

[loverustfs]

That's great! Thank you!
If you have a better solution, please submit a PR to us.

[majinghe]

@whg517 Thanks for your suggestion. Add user rustfs and run as rustfs user really a good security practice, will test your suggestion part. will update later.

[whg517]

@majinghe Yes, this idea originated from our practical experience in image security.

However, it is best to run the program using a non-root account and within the non-root group when creating the image. Choosing uid and gid to be 1000 is not the best option either. In the Linux operating system, the first non-root user is usually assigned the user ID 1000. The deployment of rustfs is aimed at achieving higher performance. It directly mounts the local disk into the container, which results in ordinary users in the system being able to directly access the files in the mounted directory. This is extremely unsafe!

In the chat I wrote, I have already solved the previous permission issues using a compatible method. My approach was to mount the volume to /export, which was based on the practice of Minio. The log directory was mounted to /var/logs/rustfs. However, for users who are new to rustfs, they will still encounter such permission issues after mounting. For example, if a disk is mounted to /data/rustfs0, then this directory will never have permissions for uid 1000.

Here is my chart: https://github.com/whg517/rustfs-chart

[majinghe]

@whg517 Per your suggestion, we modify the Dockerfile which adds rustfs user and run rustfs container with rustfs user. And the testing with docker container and k8s deployment work well. Changes in this pr.

In addition, RustFS published official helm chart, your any contribution is welcomed. Please feel free to open a pr if you think our helm chart should be improved.

Thanks again.

[whg517]

@majinghe Great! Thank you for your prompt response. I will gradually merge the chart function I have developed into your repository in the future.

[stavros-k]

If you use /rustfs/data# and user: "1000:1000" or (securityContext for k8s) it works without issues, as is.

It only fails if you use /data/<somedir># because the Dockerfile chowns /data to root, and then the entrypoint.sh runs mkdir -p /data/#which fails due to/data` being owned by root.

[majinghe]

@stavros-k We improved this part in this pr, which add rustfs user in Dockerfile and run as rustfs user. After testing in container deployment, works fine.

kubectl -n rustfs exec -it rustfs-0 -c rustfs -- /bin/sh
/ $ id
uid=1000(rustfs) gid=1000(rustfs) groups=1000(rustfs)
/ $ ls -ltr /data/
total 16
drwxrwxrwx 3 rustfs rustfs 4096 Nov  6 12:22 rustfs0
drwxrwxrwx 3 rustfs rustfs 4096 Nov  6 12:22 rustfs3
drwxrwxrwx 3 rustfs rustfs 4096 Nov  6 12:22 rustfs2
drwxrwxrwx 3 rustfs rustfs 4096 Nov  6 12:22 rustfs1
/ $ ls -ld /data/
drwxr-x--- 6 rustfs rustfs 4096 Nov  7 13:10 /data/

[stavros-k]

With This PR it runs as a specific user.
What I described above will work as any user.

[majinghe]

@whg517 For k8s deployment, we add an initContainer to change the owner for /data and /logs to ensure those two directories work as the rustfs user.

          command:
            - sh
            - -c
            - |
              if [ "$REPLICA_COUNT" -eq 4 ]; then
                for i in $(seq 0 $(($REPLICA_COUNT - 1))); do
                  mkdir -p /data/rustfs$i
                done;
              elif [ "$REPLICA_COUNT" -eq 16 ]; then
                mkdir -p /data
              fi

              chown -R 1000:1000 /data
              chown -R 1000:1000 /logs

Currently, we want rustfs to run as a rustfs user'' with an 1000 id.'' Your any suggestion for container security are welcomed.

[larivierec]

I'm running rustfs in plain docker and when it spins up now I'm getting permission denied. Had to revert to .67.

Most likely because all previous files were manipulated as root. Just an FYI

[majinghe]

@larivierec I think the permission denied caused by Dockerfile modification(add a step USER rustfs), nowadays on container condition, rustfs will run as rustfs user with id 1000, and both the /data and /logs are owned by rustfs user and group.

Please try to change the owner of data and logs and confirm whether rustfs works fine or not with latest version(68).