Open marcinc opened 6 years ago
Hey @marcinc,
feel free to contribute a pr for this case.
In addition to using non-root users inside the container, another approach to improve the security is to enable user namespaces in Docker on the host itself. https://docs.docker.com/engine/security/userns-remap/ With that enabled, each process in a Docker container is mapped to unprivileged user on the host, therefore if a process in the container managed to escape to the host, it would have no privileges there.
Below is a portion of process list on my host(the first process is the Docker on the host):
root 1814 1047 docker-containerd-shim -namespace moby -workdir /var/lib/docker/231072.231072/containerd/daemon/io.containerd.runtime.v1.linux/moby/192afd54a5756c06f7619be144a4e918d65b96840786ab3fd7cdd8b0d30e5907 -address /var/r
231072 1838 1814 /usr/bin/python /usr/bin/supervisord -nc /etc/supervisor/supervisord.conf
232072 5862 1838 /usr/local/bin/gitaly /home/git/gitaly/config.toml
232072 5910 5862 ruby /home/git/gitaly/ruby/bin/gitaly-ruby 676 /tmp/gitaly-ruby803460822/socket.0
232072 5915 5862 ruby /home/git/gitaly/ruby/bin/gitaly-ruby 676 /tmp/gitaly-ruby803460822/socket.1
232072 5863 1838 sidekiq 5.2.1 gitlab [0 of 25 busy]
232072 5864 1838 unicorn_rails master -c /home/git/gitlab/config/unicorn.rb -E production
232072 6063 5864 unicorn_rails worker[0] -c /home/git/gitlab/config/unicorn.rb -E production
232072 6066 5864 unicorn_rails worker[1] -c /home/git/gitlab/config/unicorn.rb -E production
232072 6069 5864 unicorn_rails worker[2] -c /home/git/gitlab/config/unicorn.rb -E production
232072 5865 1838 /usr/local/bin/gitlab-workhorse -listenUmask 0 -listenNetwork tcp -listenAddr :8181 -authBackend http://127.0.0.1:8080/gitlab -authSocket /home/git/gitlab/tmp/sockets/gitlab.socket -documentRoot /home/git/git
231072 5866 1838 /usr/sbin/cron -f
231072 5867 1838 nginx: master process /usr/sbin/nginx -g daemon off;
231105 5903 5867 nginx: worker process
231105 5904 5867 nginx: worker process
232072 5868 1838 /usr/local/bin/gitlab-pages -pages-domain tekux.com -pages-root /home/git/data/shared/pages -listen-proxy :8090
231072 5869 1838 /usr/sbin/sshd -D -E /var/log/gitlab/supervisor/sshd.log
This is out of scope for this project, this is more to help people secure their Docker host in general.
Hello, I have the same need. I need to start this container in a PaaS OpenShift that I am not the owner (I only have a namespace), I do not have the rights to start this container as root user (so it failed) A non-root version would be ideal.
In general what is the purpose of running as root if we can not doing it?
This issue has been automatically marked as stale because it has not had any activity for the last 60 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.
how to run as non root user in latest version? Does the latest version fix this issue?
For security reasons it would be desirable that Gitlab container runs with specific non privileged UID therefore reducing potential exposure surface.
There should be a relatively easy way to manage processes with supervisor without root access. Services currently binding privileged ports 22,80,443 could be tighten down to non-privileged range. Alternatively if current defaults are to be left as is, services could run as non-root given appropriate linux kernel capabilities.