-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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.
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
distroless/static:nonroot with runc v1.0.0-rc93 - chdir to cwd: permission denied #718
Comments
@hasheddan I've edited the issue body to fix the |
With 1001 user run-steps-as-non-root test can fail because of missing permissions, see tektoncd#3978 Possible solutions is to use 65532 user, which is configured one for gcr.io/distroless/static:nonroot base image or to change working directory to "/" from the default "/home/nonroot" as per GoogleContainerTools/distroless#718 "/" working directory allows to use not only 65532 user, so this path is chosen. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
With 1001 user run-steps-as-non-root test can fail because of missing permissions, see tektoncd#3978 Possible solutions is to use 65532 user, which is configured one for gcr.io/distroless/static:nonroot base image or to change working directory to "/" from the default "/home/nonroot" as per GoogleContainerTools/distroless#718 "/" working directory allows to use not only 65532 user, so this path is chosen. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
With 1001 user run-steps-as-non-root test can fail because of missing permissions, see #3978 Possible solutions is to use 65532 user, which is configured one for gcr.io/distroless/static:nonroot base image or to change working directory to "/" from the default "/home/nonroot" as per GoogleContainerTools/distroless#718 "/" working directory allows to use not only 65532 user, so this path is chosen. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
With 1001 user run-steps-as-non-root test can fail because of missing permissions, see tektoncd#3978 Possible solutions is to use 65532 user, which is configured one for gcr.io/distroless/static:nonroot base image or to change working directory to "/" from the default "/home/nonroot" as per GoogleContainerTools/distroless#718 "/" working directory allows to use not only 65532 user, so this path is chosen. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
With 1001 user run-steps-as-non-root test can fail because of missing permissions, see tektoncd#3978 Possible solutions is to use 65532 user, which is configured one for gcr.io/distroless/static:nonroot base image or to change working directory to "/" from the default "/home/nonroot" as per GoogleContainerTools/distroless#718 "/" working directory allows to use not only 65532 user, so this path is chosen. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
With 1001 user run-steps-as-non-root test can fail because of missing permissions, see #3978 Possible solutions is to use 65532 user, which is configured one for gcr.io/distroless/static:nonroot base image or to change working directory to "/" from the default "/home/nonroot" as per GoogleContainerTools/distroless#718 "/" working directory allows to use not only 65532 user, so this path is chosen. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
I have a scenario that is having difficulty because the permission bits on the My FROM golang:latest as builder
WORKDIR /workspace
COPY go.mod go.mod
COPY go.sum go.sum
RUN go mod download
COPY cmd/ cmd/
COPY pkg/ pkg/
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 GO111MODULE=on \
go build ./cmd/debug-http-server
FROM gcr.io/distroless/static:nonroot
EXPOSE 8443
COPY --from=builder --chown=nonroot:nonroot /workspace/debug-http-server ./
COPY --chown=nonroot:nonroot certificate.pem key.pem ./
CMD ["./debug-http-server"] The resulting permission of the relevant files are:
When it runs under OpenShift, however, using the But if the home directory had permissions of 755, the program would be able to read the files. |
The api config location was inconsistent between the code and deployment manifest. The new location was chosen based on GoogleContainerTools/distroless#718. Kubernetes v1.25 uses new types of tokens for the service accounts which are not automatically created.
The api config location was inconsistent between the code and deployment manifest. The new location was chosen based on GoogleContainerTools/distroless#718. Kubernetes v1.25 uses new types of tokens for the service accounts which are not automatically created. Bump test deployment timeout causing sporadic failures.
The api config location was inconsistent between the code and deployment manifest. The new location was chosen based on GoogleContainerTools/distroless#718. Kubernetes v1.25 uses new types of tokens for the service accounts which are not automatically created. Add postgres pod availability check and bump test deployment timeout causing sporadic failures.
The api config location was inconsistent between the code and deployment manifest. The new location was chosen based on GoogleContainerTools/distroless#718. Kubernetes v1.25 uses new types of tokens for the service accounts which are not automatically created. Add postgres pod availability check and bump test deployment timeout causing sporadic failures.
This issue is mostly informational, and is meant to potentially facilitate conversation, but does not necessarily require any changes.
You can find a complete write-up and testing in crossplane/crossplane#2245.
Some folks have recently been running into issues with images using the distroless
nonroot
image as base, where they observe the following error:To provide some background,
gcr.io/distroless/static:nonroot
image sets user asnonroot
(uid=65532
) and working directory to/home/nonroot
, which has0700
permissions. This means that only thenonroot
user canchdir
to this directory because thegroup
andother
permissions do not have execute bit. While it is expected that consumers of images built on thenonroot
image run as thenonroot
user, there are some environments, such as Openshift, which will set a random uid within a range for containers. This has not caused issues in the past becauserunc
changed to the specified working directory for the image before it setup the container user. However, a recent change that was included in thev1.0.0-rc93
release switched to first setting up the container user, then changing to the working directory. This means that if a random uid was assigned, the container user likely does not have permissions to change to the working directory, causing the error mentioned above. As various hosted Kubernetes offerings have updated to the newest version ofrunc
, folks have begun to see this more and more.The error was prevalent enough that a workaround has now been merged, and will be present in the next release. However, it is likely that a number of platforms will be using
v1.0.0-rc93
for the near term, requiring some projects to update their base image to accommodate for these scenarios.Whether a change should be made to the
nonroot
image is mostly a matter of philosophy of the image purpose: Is the intention to force users to run asnonroot
? If so, then it seems no changes are required. However, if the intention is rather to just default to users running asnonroot
, then it may make sense to make the default permissions on/home/nonroot
to0755
, or change the default working directory to/
. I tend to lean towards no change as folks can accomplish the workaround by using the plaindistroless/static
image and set uid to65532
in the top layer of their image build if they want to allow for running with other users, but default to running asnonroot
.Anyway, I wanted to share this write-up with folks in an area where they may come searching for it. It should also be helpful from a documentation perspective for just understanding how the distroless images are built. Let me know if there is anything else I can do to be of help here :)
The text was updated successfully, but these errors were encountered: