[
https://issues.apache.org/jira/browse/NIFI-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-6071.
----------------------------------
Resolution: Feedback Received
Apache NiFi 1.x is no longer maintained and no new release is planned on the
1.x release line. Marking as resolved as part of a cleanup operation. Please
open a new one with an updated description if this is still relevant for NiFi
2.x.
> Docker images not compatible with OpenShift environments
> --------------------------------------------------------
>
> Key: NIFI-6071
> URL: https://issues.apache.org/jira/browse/NIFI-6071
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.8.0, 1.9.0
> Reporter: Aldrin Piri
> Priority: Major
>
> 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.
> {quote}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.```{quote}
> This primarily seems to stem from the default UID. The reporter provided
> some additional information from the Openshift docs their requirements for
> successful operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
