Are you open to PR for K8S compliance?

Tutor
1

Hi
I wonder if you are open to PR on Github in order to make Tutor docker images compliant to run on k8s cluster that refuse to run as root (enforced by pod security policies).

I saw that elasticsearch, mysql… donc have any securityContext and tutor images don’t have dedicated user account.

Nginx docker image should be switched to nginx-unprivileged too.

I can provide such modification only if you are open to it :slight_smile:

Thanks

2

Hi @menardorama! This seems to make sense, but I must admit that I don’t know much about securityContext or pod security policies. Would you have pointers for me?

I’m open to pull requests as long as the changes do not impact the docker-compose deployments – basically as long as the Dockerfile themselves are not modified.

3

Hi @regis,

Thanks for your feedback, running docker container without a defined USERID imply that it will run as root (uid 0) which share the same uid with the root account of the docker host (or kubernetes worker node in our case).

As a security measure, it is strongly advised that you never run docker container as root in production.
For example Openshift (Redhat custom kubernetes) don"t allow to schedule pods if they run as root.

On Kubernetes there is the Pod Security Policy that can enforce it (of course you can bypass it for ingress controllers or some other validated apps).

So in order to be compliant, you need 2 things

  • Modify your Dockerfile in order to have a USER directive (and also have created a userid and a group)

  • Define it in the securitycontext in your deployment

Most of comunity docker images such as mongo or elasticsearch are already built with a user directive but if you don’t define it in the securitycontext you’ll still run as root.

So basically modifying the Dockerfile will have no impact on the other deployment type tutor offer (except maybe on the file ownership I haven’t verified yet).

I have already begun to work on it here https://github.com/menardorama/tutor/tree/securitycontext

Another remark would be with the nginx container, as you can’t bind privileged ports on an non running root container, there is a workarround with the nginx container by switching to nginx-unprivileged docker image (not working yet on my fork because of a wrong image tag.

But I suppose that it would need to update the docker-compose file.