4

I am trying to build a docker image using docker-maven plugin, and plan to execute the mvn command using jenkins. I have jenkins.war deployed on a tomcat instance instead of a standalone app, which runs as a non-root user. The problem is that docker needs to be run as root user, so maven commands need to be run as root user, and hence jenkins/tomcat needs to run as root user which is not a good practice (although my non-root-user is also sudoer so I guess won't matter much).

So bottom line, I see two solutions : Either run docker as non-root user (and need help on how to do that) OR Need to run jenkins as root (And not sure how to achieve that as I changed environment variable /config and still its not switching to root).

Any advice on which solution to choose and how to implement it ?

Sid
  • 125
  • 2
  • 11

3 Answers3

4

The problem is that docker needs to be run as root user, so maven commands need to be run as root user,

No, a docker run can be done with a -u (--user) parameter in order to use a non-root user inside the container.

Either run docker as non-root user

Your user (on the host) needs to be part of the docker group. Then you can run the docker service with that user.

As commented, this is not very secure.
See:

That last links ends with the following findings:

  • If there’s a known uid that the process inside the container is executing as, it could be as simple as restricting access to the host system so that the uid from the container has limited access.
  • The better solution is to start containers with a known uid using the--user (you can use a username also, but remember that it’s just a friendlier way of providing a uid from the host’s username system), and then limiting access to the uid on the host that you’ve decided the container will run as.
  • Because of how uids and usernames (and gids and group names) map from a container to the host, specifying the user that a containerized process runs as can make the process appear to be owned by different users inside vs outside the container.

Regarding that last point, you now have user namespace (userns) remapping (since docker 1.10, but I would advice 17.06, because of issue 33844).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Being the member of the "docker" group does grant access to the docker command, but it is also effectively the same as making the user root (seem my response). I suppose if the user in question is already a sudoer, (per the OP) this is all moot, but I'm against promoting the "docker" group as a quick fix. – Ryan Nov 18 '17 at 21:08
  • @Ryan The two issues are different. docker group or not, you still can run with a -u parameter, ensuring that the user within a container is not root. The second issue is real indeed (https://github.com/chrisfosterelli/dockerrootplease, https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf#ce09) That last link includes recommendation. – VonC Nov 18 '17 at 21:43
  • @Ryan I have edited the answer to propose alternatives. – VonC Nov 18 '17 at 21:49
  • Thanks. As good as it gets I suppose. The --user option is all well and good, but that only protects the host from poorly built containers. It doesn't protect the host from arbitrary docker commands of a local user (they can opt not to use it), which is what his jenkins daemon needs. – Ryan Nov 19 '17 at 01:50
1

I am also stuck on how to setup a docker build server.

Here's where I see ground truth right now...

  • Docker commands require root privileges

    • This is because if can run arbitrary docker commands, you have the same powers as root on the host. (You can build a container runnings as root internally, with a filesystem mount to anywhere on the host, thus allowing any root action.)

  • The "docker" group is a big lie IMHO. It's effectively the same as making the members root.

  • The only way I can see to wrap docker with any kind of security for non-root use is to build custom bash scripts to launch very specific docker commands, then to carefully audit the security implications of those commands, then add those scripts to the sudoers file (granting passwordless sudo to non-root users).

In the world where we integrate docker into development pipelines (e.g. putting docker commands in Maven builds or allow developers to make arbitrary changes to build definitions for a docker build server), I have idea how you maintain any security.

Ryan
  • 1,171
  • 1
  • 10
  • 23
0

From a lot of searching and research debugging this issue in the the last week.

I found to run a maven docker container as non root would be to pass the user flag eg -u 1000

But for this to work correctly the user needs to be in the /passwd directory of the image to work around this you can add the host (Jenkins) /etc/passwd directory to the docker image and use a non root user.

From your system commmand arguments on the docker run container add the following to mount the correct volumes to the mvn image to allow the host non root user to get mapped inside the maven container.

-v /share:/share -v /etc/passwd:/etc/passwd:ro -v /etc/group:/etc/group:ro -v "$HOME/.m2":/var/maven/.m2:z -w /usr/src/mymaven -e MAVEN_CONFIG=/var/maven/.m2 -e MAVEN_OPTS="-Duser.home=/var/maven"

I know this might not be the most informative answer but it should work to run a mvn container as non root specifically to run otj-embedded-pg for integration tests that pass fine locally but fail on a Jenkins server.

See this link OTJ_EMBEDDED_RUN_IN_CI_SERVER

As most of the posters on that thread suggest creating a new image there is no need to do that and you can run the latest maven docker image with the commands listed above and it works as it should

Hope this helps somebody that might get stuck on this issue and save them a few hours work.

James Albert
  • 31
  • 2