-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop privileges in container image so it can run securely on Kubernetes #2
Conversation
…yContext active which prohibites running privileged containers
Mounting a persistent storage volume into /fah is mandatory, not optional. There should be one for each container and it should have the config.xml preloaded - see "Running on a Cluster" in the README. The container can also be run under any UID, either by Docker (from README): docker run --gpus all --name fah0 -d --user "$(id -u):$(id -g)" \
--volume $HOME/fah:/fah foldingathome/fah-gpu:latest Or in K8s securityContext or other container orchestrators. |
The .deb package already does this. It adds a user |
There are no services in containers (in general), so the fahclient user is not what we're talking about in this case. The user a container runs as is controlled by docker/K8s/etc. The .deb is only being used to get the FAHClient binary installed and trigger dependencies. |
Ah, right it just runs the client process in the container. You should be able to add the option |
It's the |
With "omitted" I meant that you could achieve the same effect with In the above example it is assumed that the running
Hence the Meanwhile I have also kind of solved the whole problem as a whole by using an |
You are correct the UID the user chooses to run the container as, has to have read-write permissions to the persistent storage directory. The init container is a good solution in your specific case, but may not work in others. E.g. the permissions can be set during setup while creating one config.xml for each container. How that is done varies a lot by storage system, but I should have called it out explicitly in the README. I'll fix it in the morning. Thanks. |
Compute clusters have the tendency of sharing resources with mixed workloads where Folding at Home could be one of them.
To guarantee high(er) integrity of the compute clusters security and mainly integrity of the data, workload (containers) should not run in privileged mode.
In the case of Kubernetes this means that upfront inside the resource specification it needs to be known under which UID and GID the process will run.
The
VOLUME
statement inside the container could be omitted if attached during runtime of thedocker
command instead of defining this in theDockerfile
to make the image portable (across schedulers).Dropping privileges can also be done by creating an
entrypoint.sh
wrapper script, but that makes the solution less elegant and also rules out Kubernetes support with a (stricter)securityContext
set since the container starts asroot
, but later on drops it out of Kubernetes-es line of sight.