Closed Birdrock closed 3 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/175749977
The labels on this github issue will be updated when the story is started.
Hi @Birdrock we are closing this issue due to the investigations and findings part of https://github.com/cloudfoundry-incubator/eirini/pull/121 -> referring to @gcapizzi his comment https://github.com/cloudfoundry-incubator/eirini/pull/121#issuecomment-737878812
Description
Docker staging does not inspect images for a
USER
directive. When a Docker image does not specify aUSER
or specifies aUSER
as a string, the desired LRP will have aCreateContainerConfigError
with events showingError: container has runAsNonRoot and image will run as root
orError: container has runAsNonRoot and image has non-numeric user (<some-user-string>), cannot verify user is non-root
.This is because the
PodSecurityContext
specifiesRunAsNonRoot
. Images that don't specify aUSER
will try to default to UID 0 (root). Images that specify aUSER
string don't meet the requirements forRunAsNonRoot
- Kubernetes requires a non-zero numeric user. (https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups)Steps to reproduce
cf push hello-ruby -o awittrock/helloworld-ruby
What was expected to happen
Container starts successfully.
What actually happened
Error: container has runAsNonRoot and image will run as root
Suggested fix (optional)
Docker staging inspects image and adds user metadata to payload. cloud_controller_ng appends this data to the desired LRP request for use in the
PodSecurityContext
. ThePodSecurityContext
respects the user provided bycloud_controller_ng
if it is specified as a numeric user. ThePodSecurityContext
provides a default value for requests that do not specify a user (empty string) or provide a non-numeric user.Additional information (optional)
We've done an exploration and test drove the implementation. We will submit a PR once we have done the necessary work on
cloud_controller_ng
.