Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bug 1904538: Dockerfile.ocp: specify numeric uid #36

Merged
merged 1 commit into from
Dec 10, 2020
Merged

Bug 1904538: Dockerfile.ocp: specify numeric uid #36

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion Dockerfile.ocp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,6 @@ LABEL io.k8s.display-name="kube-rbac-proxy" \
ARG FROM_DIRECTORY=/go/src/github.com/brancz/kube-rbac-proxy
COPY --from=builder ${FROM_DIRECTORY}/_output/kube-rbac-proxy /usr/bin/kube-rbac-proxy

USER nobody
USER 65534
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we just want this to be nobody but numericly?

In CMO we use another user UID, hence the question.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct, we still want this to be nobody, but numeric. the whole problem is that if we use the literal string "nobody" non-numerically, along with the nonroot security context constraint, the provisioning will fail with the following error:

container has runAsNonRoot and image has non-numeric user (nobody), cannot verify user is non-root

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and we tried removing the nonroot security context constraint from CMO alltogether, but that didn't work of the following provisioning error: openshift/cluster-monitoring-operator#1015 (comment)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation!!

/hold cancel

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

side note: i am not very happen about the solution to be honest, the question around the mystery why cluster-monitoring-operator sometimes gets nonroot assigned vs. restricted still remains (hypothesis so far is some race in the provisioning controller). Additionally, i do get the necessity for cluster-monitoring-operator needs to have the same security context constraint, but it is not really necessary for the pod runtime as we don't mount things there.

EXPOSE 8080
ENTRYPOINT ["/usr/bin/kube-rbac-proxy"]