[NIFI-6071] Docker images not compatible with OpenShift environments

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.8.0, 1.9.0
• Assignee: Unassigned
• Reporter: Aldrin Piri
• Created: 22/Feb/19 15:45
• Updated: 03/Nov/20 07:19

Description

This was reported on the Apache NiFi slack (https://apachenifi.slack.com/archives/C0L9VCD47/p1550739304031100?thread_ts=1550684518.023100&cid=C0L9VCD47)

This was verified problematic on 1.8.0 but likely is also an issue well before that version.

juv [1 day ago]
@aldrin The docker image is not working for us on OpenShift. This is the output of the container (yes, that's all):
```replacing target file /opt/nifi/nifi-current/conf/nifi.properties
sed: can't read /opt/nifi/nifi-current/conf/nifi.properties: No such file or directory```
(edited)

juv [1 day ago]
This looks like a permission issue. The docker image is not properly setting permissions on the files when the image is running in non-privileged mode (this is the case on OpenShift) (edited)

juv [1 day ago]
One small thing: the dockerfile is using `ADD sh/ ${NIFI_BASE_DIR}/scripts/`. In general, when special `add` functionality is not needed (e.g. for having a <src> parameter which is an URL), one should use `copy` instead: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#add-or-copy – is there a reason the dockerfile uses `add` instead of `copy`? (edited)
Docker Documentation
Best practices for writing Dockerfiles
This document covers recommended best practices and methods for building efficient images. Docker builds images automatically by reading the instructions from a Dockerfile – a text file that contains all...
Feb 20th

aldrin [1 day ago]
hmmm… would you mind filing a ticket? will have to investigate what changed on the dockerfile

aldrin [1 day ago]
you were using 1.8.0 successfully?

aldrin [1 day ago]
not seeing any meaningful changes in the docker work over the last two releases and have been using the docker image in a few different contexts unprivileged

juv [1 day ago]
@aldrin I have checked with my colleagues. 1.8.0 is also not working. It's working for us now because we use a workaround. We run Nifi with a service account in Kubernetes that is allowed to use the `anyuid` security context constraint.

juv [1 day ago]
Usually, pods are not allowed to claim the uid 1000 in OpenShift

juv [1 day ago]
We generally follow the openshift guidelines in our dockerfiles, see "Support Arbitrary User IDs" here: https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html#openshift-specific-guidelines

juv [1 day ago]
As an example, when I run `id` within a container with abitrary user id support: `uid=1011370000 gid=0(root) groups=1011370000`, for the nifi container it looks like this `uid=1000(nifi) gid=1000(nifi) groups=1000(nifi),2080,2081,2082,2084,2085,2086,2087` (edited)

juv [1 day ago]
So basically in our Dockerfile, we switch user to `1001`, openshift takes that user id and generates a new unique one, `1001 --> 1011370000` in this case. Because the container user is always member of the root group (note: not root user), we can then change the group ownership to the root group:
```RUN chgrp -R 0 /some/directory && \
chmod -R g=u /some/directory```
and everything will run smoothly

aldrin [23 hours ago]
understood. I haven’t worked with OpenShift, but it seems like providing the ability to config around that scenario wouldn’t be too bad

aldrin [23 hours ago]
we do actually treat uid and guid as build args as per https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile#L23
GitHub
apache/nifi
Mirror of Apache NiFi. Contribute to apache/nifi development by creating an account on GitHub.

aldrin [23 hours ago]
so instead of having to roll your own dockerfile, you could just use the source with openshift compliant ids incorporated

aldrin [23 hours ago]
would you like to report this issue in JIRA? otherwise I can take the items listed here and create one around them

juv [4 hours ago]
I don't think setting the user id as build arg will work because of this requirement:
```Lastly, the final USER declaration in the Dockerfile should specify the user ID (numeric value) and not the user name. This allows OpenShift Container Platform to validate the authority the image is attempting to run with and prevent running images that are trying to run as root, because running containers as a privileged user exposes potential security holes. If the image does not specify a USER, it inherits the USER from the parent image.```

This primarily seems to stem from the default UID. The reporter provided some additional information from the Openshift docs their requirements for successful operation.