Run/Install Harbor as non-root user

[AlexBarth13]

Hi all,

We are using Harbor v2.5.0 in Docker Container on a Linux Virtual Machine.
During some tests, we noticed that those Containers have to run as root users. If we were trying to start them as non-root users, we had the following issue:

[Step 4]: starting Harbor ... Traceback (most recent call last): File "bin/docker-compose", line 6, 
in <module> File "compose/cli/main.py", line 71, in main File "compose/cli/main.py", line 124,
in perform_command File "compose/cli/command.py", line 42, 
in project_from_options File "compose/cli/command.py", line 115, 
in get_project File "compose/config/config.py", line 402, in load File "compose/config/config.py", 
line 502, in load_services File "compose/config/config.py", 
line 481, in build_services File "compose/config/config.py", 
line 481, in <listcomp> File "compose/config/config.py", 
line 473, in build_service File "compose/config/config.py", 
line 846, in finalize_service File "compose/config/config.py",
line 658, in resolve_environment File "compose/config/environment.py", 
line 35, in env_vars_from_file File "/code/.tox/py36/lib/python3.6/codecs.py", 
line 897, in open PermissionError: 
[Errno 13] Permission denied: '/opt/harbor/v2.5.0/common/config/registryctl/env' [21216] Failed to execute script docker-compose

Are there any plans to change this in the future to increase security?

Thank you in advance!

Alexander Barth (alexander.barth@mercedes-benz.com) on behalf of Mercedes-Benz Tech Innovation GmbH, Provider Information

[rrgadeev]

https://docs.docker.com/engine/install/linux-postinstall/
sudo usermod -aG docker $USER
chown $USER:$USER -R /opt/harbor

[larsl-net]

Same problem.
The following files are required to run docker compose commands, but are only readable by root:root, which seems to be the the problem.

$ cat docker-compose.yml | grep env_file -A1
    env_file:
      - ./common/config/registryctl/env
--
    env_file:
      - ./common/config/db/env
--
    env_file:
      - ./common/config/core/env
--
    env_file:
      - ./common/config/jobservice/env
--
    env_file:
      - ./common/config/exporter/env
$ ls -Al common/config/*/env
-rw-r----- 1 root root 1807 Sep 15 12:22 common/config/core/env
-rw-r----- 1 root root   25 Sep 15 12:22 common/config/db/env
-rw-r----- 1 root root  759 Sep 15 12:22 common/config/exporter/env
-rw-r----- 1 root root  585 Sep 15 12:22 common/config/jobservice/env
-rw-r----- 1 root root   64 Sep 15 12:22 common/config/registryctl/env

[alexanderdalloz]

Yes, I strongly encourage the maintainers to provide Harbor images and a setup which does not run the containers as root.

[AlexBarth13]

Hi @MinerYang and @wy65701436!
Is there any planning to implement this to improve the security?

Thanks!


Alexander Barth (alexander.barth@mercedes-benz.com) on behalf of Mercedes-Benz Tech Innovation GmbH, Provider Information

[Atomique]

I am using v2.6.0 and tried to install it with the installation-script (docker-compose). I also cant run it with a specific harbor-user and would be interested into running it without root.

Thanks a lot

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[cdm-arm]

This shouldn't be stale, as the question of @AlexBarth13 was never answered.

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[cdm-arm]

Hi @reasonerjt, @steven-zou - maybe in your roles as tech lead and chief architects of Harbor could give an advisory to the community or to @stonezdj how to best handle. I think running containers as root without a real requirement for it is a security flaw that counter strikes the ideas of k8s deployments.

[ngoeddel-openi]

Just got the same issue here with Harbor 2.8.0. Please give us the possibility to use a non-root user or a detailed instruction how to change it afterwards.

[invy]

I find the problem pretty strange. Why does harbor need root user?
I have an ugly workaround for the user, which can docker but does not have sudo (still I think it would be easier to make user sudo-capable).
Just use docker in docker, i.e.:

docker run -v /var/run/docker.sock:/var/run/docker.sock \ 
-v /srv:/srv --rm -it \
docker /bin/sh -c \
"apk update && apk upgrade && apk add bash && apk add ncurses && apk add docker-compose && cd /srv/container/harbor && ./install.sh --with-trivy --with-notary"

[alexanderdalloz]

Instead of mounting the docker socket you could simply add the non-root user to the docker group.

[invy]

Instead of mounting the docker socket you could simply add the non-root user to the docker group.

This is not the problem with the rights to execute docker, the problem is, that the prepare container from harbor runs as root (which containers do). So that the following tries to access docker-compose.yml or configs in common dir will fail if you are not root.

Clean up the input dir


Note: stopping existing Harbor instance ...
Failed to load /srv/container/harbor/common/config/jobservice/env: open /srv/container/harbor/common/config/jobservice/env: permission denied
$ ls -lh /srv/container/harbor
total 88K
-rw-rw-r-- 1 igor igor 2,0K Jul 11 08:18 ca.crt
-rw------- 1 igor igor 3,2K Jul 11 08:18 ca.key
drwxr-xr-x 3 root root 4,0K Jul 11 08:18 common
-rw-r--r-- 1 igor igor 3,6K Jun  2 13:46 common.sh
-rw-r--r-- 1 root root 8,3K Jul 11 08:18 docker-compose.yml
-rw-rw-r-- 1 igor igor 9,5K Jul 11 08:18 harbor.yml
-rw-r--r-- 1 igor igor  12K Jun  2 13:46 harbor.yml.tmpl
-rwxr-xr-x 1 igor igor 2,7K Jun  2 13:46 install.sh
-rw-r--r-- 1 igor igor  12K Jun  2 13:46 LICENSE
-rwxr-xr-x 1 igor igor 1,9K Jun  2 13:46 prepare
-rw-rw-r-- 1 igor igor  259 Jul 11 08:18 v3.ext

So in this situation you are kinda stuck and you would still need root / docker to work around the permissions issue.
And even if so, you'll still be careful when you are updating harbor, because, you'll run prepare container again which would gladly overwrite files and could set permissions again.
This is the reason harbor suggest 'sudo' because it's pragmatically easier then everything else to workaround permissions issue.

[invy]

Funnier again, the files inside of config have different ownership:

/srv/container/harbor/common/config$ ls -lh
total 44K
drwxr-xr-x 3 root  root  4,0K Jul 11 08:18 core
drwxr-xr-x 2 root  root  4,0K Jul 11 08:18 db
drwxr-xr-x 2 10000 10000 4,0K Jul 11 08:18 jobservice
drwxr-xr-x 2 root  root  4,0K Jul 11 08:18 log
drwxr-xr-x 3 root  root  4,0K Jul 11 08:18 nginx
drwxr-xr-x 2 root  root  4,0K Jul 11 08:18 notary
drwxr-xr-x 2 10000 10000 4,0K Jul 11 08:18 portal
drwxr-xr-x 2 root  root  4,0K Jul 11 08:18 registry
drwxr-xr-x 2 root  root  4,0K Jul 11 08:18 registryctl
drwxr-xr-x 3 root  root  4,0K Jul 11 08:18 shared
drwxr-xr-x 2 root  root  4,0K Jul 11 08:18 trivy-adapter

So again, chowning everything here would probably break portal, and jobservice...
Maybe if that container are not that 'picky' you can work around the issue with adding write permission to everyone. But it is still ugly...

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[cdm-arm]

@wy65701436 any hints on when someone may find some time to look at this? This seems like an issue that requires attention however community didn't see any comment in over a year now.

[clamprecht01]

Following for (hopeful) updates.

[dzr-gregory]

Harbor v2.7.3, we also faced with this issue. Taking into account that running container as root user definitely isn't the best way to deploy services, that's very strange that no solution for this issue is provided. Also, running "docker-compose" command under "root" user leads to another problem - you have to manually run "docker-compose up ..." after machine reboot since most of project containers are not able to start

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[cdm-arm]

Hi @MinerYang and @wy65701436

Is there anything that could be contributed? Any hint into the right direction would be appreciated.

[dlewis7444]

@cdm-arm I'm using Bitnami's release of rootless Harbor. It's less than ideal as their documentation is weak if you're not running it on AWS or K8s. But I got it working on a bare RHEL 8 box.

[Tanloon]

It has been so many years now, but this issue is still active and has not been fixed. o(╥﹏╥)o

[Suppi123]

I think I found a solution. I executed the following commands during the installation (my non-root user is named docker_user):

As root user:

- wget https://github.com/goharbor/harbor/releases/download/v2.10.0/harbor-online-installer-v2.10.0.tgz
- tar xzvf harbor-online-installer-v2.10.0.tgz
- docker run -v /:/hostfs goharbor/prepare:v2.10.0 gencert -p /path/to/internal/tls/cert
- ./install.sh --with-trivy
- docker compose down
- cd ..
- chown -R docker_user:docker_user harbor

Then I ran the installation again as non-root (in this step, the permissions are partially adjusted correctly):

- ./install.sh --with-trivy

Then I had to adjust the permissions for various env files (as root):

- chown docker_user:docker_user common/config/jobservice/env
- chown docker_user:docker_user common/config/db/env
- chown docker_user:docker_user common/config/registryctl/env
- chown docker_user:docker_user common/config/trivy-adapter/env
- chown docker_user:docker_user common/config/core/env

I was then able to start the container as docker_user:

- docker compose up -d

[MinerYang]

Hi all,

There's 2 main reason that we are not set harbor offline-installation ruining as non-root.

• data_volume dir is set as /data as default , includes several secrets, keys and certificates, config files, each of these has different permissions and need performs operations such as creating directories, executing script or only read etc. , these operations require elevated privileges. For sure you could set another non-root directory for this, but need to adjust each of these files permissions yourself without root privilege and working properly and securely.
• we are using rsyslog as our docker logging driver, although it is listening at 1514:10514 port and could drop privilege per this doc, we still need promise several configuration files as long as /var/log/docker with correct permissions to get rsyslogd started normally inside a container and cooperated with other harbor components.

Thus we are not now have no plans to enable running offline-installer as non-root officially. Instead you could choose to use harbor-helm to get rid of this concern.

[guidojw]

Hi all,

There's 2 main reason that we are not set harbor offline-installation ruining as non-root.

• data_volume dir is set as /data as default , includes several secrets, keys and certificates, config files, each of these has different permissions and need performs operations such as creating directories, executing script or only read etc. , these operations require elevated privileges. For sure you could set another non-root directory for this, but need to adjust each of these files permissions yourself without root privilege and working properly and securely.
• we are using rsyslog as our docker logging driver, although it is listening at 1514:10514 port and could drop privilege per this doc, we still need promise several configuration files as long as /var/log/docker with correct permissions to get rsyslogd started normally inside a container and cooperated with other harbor components.

Thus we are not now have no plans to enable running offline-installer as non-root officially. Instead you could choose to use harbor-helm to get rid of this concern.

Thanks for (finally 🙃) explaining that! I think this information could use a proper place in documentation somewhere.

[dlewis7444]

Bitnami managed it. We're running their version now. I like @Suppi123 's solution too. I would have tried that if I hadn't already got Bitnami to work.

[ngoeddel-openi]

Bitnami managed it. We're running their version now. I like @Suppi123 's solution too. I would have tried that if I hadn't already got Bitnami to work.

I also found out about the Bitnami image recently and will use it in the future. non-root containers are possible and we like them more here.

[MinerYang]

Bitnami managed it. We're running their version now. I like @Suppi123 's solution too. I would have tried that if I hadn't already got Bitnami to work.

I also found out about the Bitnami image recently and will use it in the future. non-root containers are possible and we like them more here.

harbor-helm also running as non-root

[OrlinVasilev]

@ngoeddel-openi and @dlewis7444 are you running on Kubernetes or docker host with docker-compose?

[ngoeddel-openi]

@ngoeddel-openi and @dlewis7444 are you running on Kubernetes or docker host with docker-compose?

We run it with docker compose because it is used as the source for our Kubernetes clusters. It's basically a chicken-or-the-egg problem. It makes no sense for us to create a dedicated Kubernetes cluster with all its overhead just to run Harbor. ;-)

[dlewis7444]

@ngoeddel-openi and @dlewis7444 are you running on Kubernetes or docker host with docker-compose?

We run it with docker compose because it is used as the source for our Kubernetes clusters. It's basically a chicken-or-the-egg problem. It makes no sense for us to create a dedicated Kubernetes cluster with all its overhead just to run Harbor. ;-)

Same - although podman not docker.