CODEWITHSUNDEEP
securitynginxdockeropenshiftopenshift-origin
brian moriarty
brian moriarty

Reputation: 23

What is the correct way to run an nginx docker container in OpenShift?

RedHat OpenShift runs docker containers as random user IDs.

This works fine for some containers, but the NGINX container requires file permissions to be set to world read/write/execute in order to work.

Is there a more correct way to build/run a container for use with OpenShift?

For example, does OpenShift provide any kind of process ownership groups or rules?

Here is the nginx image I pull down, and the chmod command we currently run to make it work in OpenShift.

registry-nginxinc.rhcloud.com/nginx/rhel7-nginx:1.9.2

RUN chmod -R 777 /var/log/nginx /var/cache/nginx/ \
&& chmod -R 777 /var/run \
&& chmod -R 777 /etc/nginx/*

References:

http://mailman.nginx.org/pipermail/nginx-devel/2015-November/007511.html

https://github.com/fsimorbrian/openshift-secure-routes

Why does this openshift route succeed in CDK but fail in RHEL7 Atomic?

Upvotes: 2

Views: 3641

Answers (1)

Graham Dumpleton
Graham Dumpleton

Reputation: 58523

Best practice is that you do not run your containers as root. Many Docker images out there, even some official images, ignore this and require you to run as root. Advice is generally that you should set up the image so that your application doesn't require root and can start up as a non root user you set up in the Dockerfile. Even this advice though isn't the most secure option for a couple of reasons.

The first is that they will say to use USER username, where username is obviously not root. For a platform that is hosting that image, that doesn't actually guarantee your application isn't running as root. This is because a named user such as username could be mapped to uid of 0 in the container and so still running with root privileges. To allow a platform to properly verify that your image isn't set up to run as root, you should use a uid instead of username. That should be anything except uid of 0.

The second problem is that although running as a specific non root user in your own Docker service instance may be fine, it isn't when you consider a multi tenant environment, be that for different users, or even different applications where it is important that the different applications can't access each other in any way.

In a multi tenant environment, the safest thing you can do is to run all applications owned by a specific account, or in different projects, as different users. One reason this is import is from the perspective of data access on persistent volumes. If everything was running as the same user and it managed to get access to persistent volumes it shouldn't, it could see data from other applications.

As far as OpenShift goes, by default it runs with the highest level of security to protect you. Thus, applications in one project are run with a different user to applications in another project.

You can reduce the security measures and override this if you have the appropriate privileges, but you should only make changes if you are comfortable that the application you are doing it for has a low risk profile. That is, you don't grab some arbitrary Docker image off the Internet you don't know anything about and let it run as root.

To learn more about changing the security context constraints around a specific application start by reading through:

You can override the default and say that an image can run as the user it declares in the Dockerfile or even run it as root if need be.

The better way if want the best security is to construct the Docker image so that it can run as any user and not just a specific user.

The general guidelines for how to do this are:

  • Create a new user account in the container to run the application as. Make the primary group of this account be group ID 0. That is, its group will be that of root, but the user will not. It needs to be group ID 0 as that is what UNIX will default the group to if running as a user that has no entry in the UNIX passwd file.
  • Any directories/files that the application needs read access to should be readable/accessible by others, or readable/accessible by group root.
  • Any directories/files that the application needs write access to should be writable by group root.
  • The application should not require the ability to bind privileged ports. Technically you could workaround that by using Linux capabilities, but some build systems for Docker images, such as Docker Hub automated builds, appear not to support you using aspects of Linux capabilities and so you wouldn't be able to build images using those if needing to use setcap.

Finally, you will find that if using OpenShift Local (CDK) from Red Hat, or the all-in-one VM for OpenShift Origin, that none of this is required. This is because those VM images have purposely been set up to allow as the default policy the ability to run any image, even images wanting to run as root. This is purely so that it is easier to try out arbitrary images you download, but in a production system you really want to be running images in a more secure way, with the ability to run images as root off by default.

If you want to read more about some of the issues around running containers as root and the issues that can come up when a platform runs containers as an arbitrary user ID, have a look at the series of blog posts at:

Upvotes: 4

Related Questions