fix: Unprivileged container image

[baptistegh]

Summary

This PR introduces support for running container images in an unprivileged mode. It removes the requirement for elevated permissions and improves overall security by isolating runtime operations from host privileges.

Details:

• Adds an unprivileged image execution path
• Create a new user starlake inside the container
• This user has UID=1001 and GID=0 as requested in the Openshift guidelines.
• Theses changes also insure that a random uid can run the binaries without issues if he belongs to the GID=0 group

Why:
Improves security posture, reduces attack surface, and aligns with best-practice least-privilege principles.

PR Type: Bug Fix | Feature | Documentation

Status: WIP

Breaking change? No

Description

Other changes

Small fixes in the docker scripts.

Remaining Todos

This should be done before merging this PR:

• Ensure the docker compose still works fine (it may require to add user: 0 on the containers needing privileges).

Contributor checklist:

Go over all the following points, and put an x in all the boxes that apply.

If you're unsure about any of these, don't hesitate to ask. We're here to help!

• My code follows the code style of this project.
• I have updated the Release notes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[fupelaqu]

LGTM except the impact on docker-compose

[fupelaqu]

there should be 2 specific entries, one for publishing and another one for building

[baptistegh]

There was no [ "$PUBLISH" = "true" ] in this script.
The -p was given if BUILD=true.
Should I fix this ?

[fupelaqu]

It will be necessary to update the docker-compose files in order to mount the different file systems (probably by adding an initialization phase for the affected containers with the necessary privileges to mount the file systems).