Jkube: Docker image root requirement

[carljmosca]

I am using a custom Java Tomcat image which does not run as root.

When doing a mvn k8s:build I am seeing this error:

Failed to execute goal org.eclipse.jkube:kubernetes-maven-plugin:1.0.0-rc-1:build (default-cli) on project jsf-primefaces-apache-tomcat: Failed to execute the build: Error while trying to build the image: Unable to build image [jsf-primefaces-demo] : "The command '/bin/sh -c chown -R root /tmp/28bb7591-77ce-4ff0-859b-38239fd8e519 && cp -rp /tmp/28bb7591-77ce-4ff0-859b-38239fd8e519/* / && rm -rf /tmp/28bb7591-77ce-4ff0-859b-38239fd8e519' returned a non-zero code: 1" -> [Help 1]

Is there currently any way to get around the requirement to change ownership to the root user?

We generally run as unknown (not predictable UID) users which are in the root group as we have seen done in some of the Red Hat images which run on OpenShift with default security settings.

[carljmosca]

I did not have the understanding of the assembly section of the build section. I am past this issue now so I will close it but I am wondering about the need for root.

[rohanKanojia]

Running images as a non-root user seem quite a common use-case to me. @manusa WDYT??

[manusa]

Hi,

In general, images are not run as any specific user by default. This is especially important for S2I built images since OpenShift doesn't allow to run containers as specific users by default.

Regarding the use of root for assembly purposes (when another user is provided in the configuration) you can read more in the assembly section of our docs.

User and/or group under which the files should be added. The user must already exist in the base image.It has the general format user[:group[:run-user]]. The user and group can be given either as numeric user- and group-id or as names. The group id is optional.

If a third part is given, then the build changes to user root before changing the ownerships, changes the ownerships and then change to user run-user which is then used for the final command to execute. This feature might be needed, if the base image already changed the user (e.g. to 'jboss') so that a chown from root to this user would fail.

For example, the image jboss/wildfly use a "jboss" user under which all commands are executed. Adding files in Docker always happens under the UID root. These files can only be changed to "jboss" is the chown command is executed as root. For the following commands to be run again as "jboss" (like the final standalone.sh), the plugin switches back to user jboss (this is this "run-user") after changing the file ownership. For this example a specification of jboss:jboss:jboss would be required.

So if you want to customize the assembly user you can use the following:

<jkube.generator.webapp.user>1000:1000</jkube.generator.webapp.user> (No run user)

<jkube.generator.webapp.user>1000:1000:1000</jkube.generator.webapp.user> (will add USER 1000)

The first pair is the user:group for assembly, the last is the run user. This will generate a Dockerfile with lines like:

COPY /deployments /tmp/2430f958-1bb2-44f0-9142-e608560f04bc/deployments/
USER root
RUN chown -R 1000:1000 /tmp/2430f958-1bb2-44f0-9142-e608560f04bc && cp -rp /tmp/2430f958-1bb2-44f0-9142-e608560f04bc/* / && rm -rf /tmp/2430f958-1bb2-44f0-9142-e608560f04bc
USER 1000
CMD /usr/local/s2i/run

However, if you are using a complete custom xml-configuration then maybe you're hitting into this, so just provide your own user for assembly purposes.

I'm not really sure why the root user is provided, this was added in #47.

I can see the maven default in DMP, but can't see anything regarding this user. @rohanKanojia do you know where this came from?

[carljmosca]

Thank you @manusa

The first part of your explanation is consistent with our practice. I am sorry if that was not clear from my original text.

I am reopening as it seems that the origin of the root user should be tracked/removed.