Portainer and Agent runs under the user root

[buehlmannpa]

We scan our running docker images with the cis benchmark and we see that both the agent and portainer itself are running under the user root.

=== CIS Compliance Report for Container Portainer ===
[NOT-OK] CIS x.x ContainerID xxxxxxxxxxx uses container user root.
[NOT-OK] CIS x.x ContainerID xxxxxxxxxxx has a sensitive host volume RW mounted /var/run/docker.sock

For us that's a security risk and my question is now:
Is it possible to use another user in the agent and portainer so that the cis checks no longer generate security messages?

That would be a big increase in safety for Portainer and the agent.

[deviantony]

We'll need to investigate this as Portainer might require root access to be able to use /var/run/docker.sock for local endpoint management and the agent requires access to the /var/run/docker.sock file.

This could be potentially worked around but requires some configuration on the Docker daemon side too to allow another user to use these files.

[deviantony]

Worth having a look at https://medium.com/@lizrice/non-privileged-containers-based-on-the-scratch-image-a80105d6d341

[attzonko]

I have been trying to get this to work as well and managed to do so today.

The /var/run/docker.socket file seems to have RW permissions for the docker group by default. So all I had to do is run the portainer container as a user (in my case the username is zonk) which was a member of the docker group.

docker run --user $(id -u zonk):$(cut -d: -f3 < <(getent group docker)) ...

[stale[bot]]

This issue has been marked as stale as it has not had recent activity, it will be closed if no further activity occurs in the next 7 days. If you believe that it has been incorrectly labelled as stale, leave a comment and the label will be removed.

[stale[bot]]

Since no further activity has appeared on this issue it will be closed. If you believe that it has been incorrectly closed, leave a comment and mention @itsconquest. One of our staff will then review the issue.
Note - If it is an old bug report, make sure that it is reproduceable in the latest version of Portainer as it may have already been fixed.

[deviantony]

Issue should not have been marked as stale as we did not investigate it yet.

[ibnesayeed]

For the future reference, when the experimental rootless docker is run, it sets the socket file location to $XDG_RUNTIME_DIR/docker.sock by default (where the value of XDG_RUNTIME_DIR is usually set to /run/user/$UID).

[mven]

I'm using rootless docker and I was experiencing the same thing with portainer. I changed the docker command to reflect @ibnesayeed's comment and I can also see containers that I've spun up as rootless in the dashboard (which I wasn't able to before):

# find your user's docker.sock
ls $XDG_RUNTIME_DIR/docker.sock
/run/user/1000/docker.sock

# then use this value in the volume param
docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /run/user/1000/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

[hgolden]

@mven wrote:

docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /run/user/1000/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

Even better, in the above command, replace /run/user/1000 with ${XDG_RUNTIME_DIR}. Then the preceding ls command isn't needed.