Reference the numerical UID for the Docker images to run as.

[KashifSaadat]

In Kubernetes when making use of PodSecurityPolicies with MustRunAsNonRoot set, the kubelet rejects any pods with a non-numeric USER.

Changes:

• For the mysql-agent image, reference the numerical id for the mysql user (created as part of the package install in the source image)
• For the mysql-operator image, create and reference a non-root user to run the image with

[KashifSaadat]

Just a note on this.. I'm not overly keen on specifying the ID for the mysql user directly in the Dockerfile as that user is created via package install in the source image (we don't have control on the id for the user, unless we create a new different user and chown file permissions).

Unfortunately there doesn't appear to be a way to export the value of a RUN command (such as id -u mysql) to then pass into the USER command. The way to do it would be to execute something like the following in the Makefile (with relevant error handling):

MYSQL_UID=`docker run --entrypoint id mysql/mysql-server:8.0.12 -u mysql`
docker build --build-arg MYSQL_UID=${MYSQL_UID} -t mysql-agent -f docker/mysql-agent/Dockerfile .

If that is preferred, let me know and I can change the approach in the PR.

[prydie]

@KashifSaadat Would using https://github.com/tianon/gosu / https://github.com/ncopa/su-exec in an entrypoint script solve the issue without requiring the hardcoding of a uid we don't control?

[KashifSaadat]

Hey @prydie, unfortunately no. The code in Kubernetes for verifyRunAsNonRoot checks the ImageSpec for the built image before execution, validating that the User attribute is defined as expected. Related code is here: https://github.com/kubernetes/kubernetes/blob/v1.11.3/pkg/kubelet/kuberuntime/kuberuntime_container.go#L191-L199

A user can get around this by defining the securityContext in their PodSpec similar to below (which takes precedence over the check on the ImageSpec):

securityContext:
  runAsUser: 27

[KashifSaadat]

I have added a second commit to avoid hardcoding the UID for the mysql-agent image build: 0510134

Just more bash in the Makefile unfortunately.

[prydie]

@KashifSaadat Currently the project wercker.yml doesn't use the Dockerfiles to create the images as previously Wercker didn't support building images directly from Dockerfiles.

For your change to have any effect on the release / CI images we need to change how we build images in the Wercker pipeline (see: here). Are you interested in giving it a shot?

[KashifSaadat]

Hey @prydie, I've never used wercker before but given it a go, commits (I can squash / cleanup once we have the right approach):

1. d4dbddc (image builds in separate pipeline)
2. ac30cd3 (re-use existing and change steps)

Could you suggest the best way to validate this? I've added and reworked the existing build pipelines, although I can't seem to see the new steps being executed or the log output of push-operator-image, which is now failing. Do you manually control / enable pipelines within the repo settings in wercker?

[KashifSaadat]

I've activated the repo in wercker for my fork to attempt to debug this further, ran into a few issues:

• With the approach of re-using the Makefile steps (running docker commands to build): https://devcenter.wercker.com/development/pipelines/direct-docker-access/
  • Turns out I can't do this, because of the note at the top of the page: This is a new feature and is currently restricted to specific users. Contact the Wercker team if you would like to use it. - Would you be able to request and have this enabled for the project?
• Using the internal/ docker steps:
  • I attempt to follow the same process as in the Makefile, extracting the mysql-agent image from the Dockerfile to docker-run and get the UID. This fails, because when referencing the env variable in a script step to the docker-run step, for some reason it fails to parse and complains that image has not been set. If I directly set the image name, the next problem is actually running a docker exec / command to extract the UID for following steps (doesn't seem to be possible due to limitations with the internal steps).
  • If I ignore the above and just try to do a simple internal/docker-build, referencing the Dockerfile and build-args (as per: https://devcenter.wercker.com/administration/containers/building-an-image/#properties), it just fails immediately with 0 log output. Possibly a bug, only occurs if I have a different base-path set.

Any thoughts?