docker-openresty
docker-openresty copied to clipboard
openresty
Add nginx (or openresty user) to run nginx
Similar to the official nginx docker container it would be ideal to run the openresty nginx server as a non root user. https://github.com/nginxinc/docker-nginx/blob/25a3fc7343c6916fce1fba32caa1e8de8409d79f/stable/alpine/Dockerfile#L52
This would simplify the handling of nginx.conf quite a bit. Because the nginx user is not present in the openresty container the nginx.conf can't contain a line like user nginx;. For a non container deployment it's recommended to use a non root user. For this reason I run openresty under nginx with the nginx.conf directive of user nginx;. I need to maintain two different nginx.conf file for a container runtime and a non container runtime.
I'm on the fence with this. I see the convenience for your config file. I was wondering if it is bad security practice to add a user that is not needed by the image itself? But, it's in a container and running as user nginx gives less privileges. Maybe it doesn't matter. The OpenResty RPM packages don't do this.
It certainly is easy to add. You can also easily derive your own image, with whatever other plugins and libraries you want. I also know it is great to just pull from Docker Hub.
@agentzh Do you have an opinion on this? Is there a reason the RPMs don't do it? Will the DEBs do it?
It is easy enough for me to add and maintain.
If I do add it, should the user be nginx or something like resty?
@neomantra Because the nobody user is the default of the official NGINX source distribution and it is universally available.
Introducing a dedicated nginx user complicates things though I admit it might be more flexible when the user wants special permission management. But anyway, the user can specify the worker user in her own nginx.conf anyway. I don't see a reason for the official packages to worry too much about that at the cost of complicating stuff and breaking standard source distribution behaviors.
OpenResty's upcoming official deb packages will follow the rpm packages strictly.
So I did a little more investigation... something that is annoying is that the nginx Docker images do not specify the UID when they create their users. So the /etc/passwd entries are different between images; alpine has nginx:x:100:101:Linux User,,,:/var/cache/nginx:/sbin/nologin and the Jessie images have nginx:x:104:107:nginx user,,,:/nonexistent:/bin/false.
Docker uses the UID, not the name. So you won't easily be able to share files between the host and the container, unless they are sync'ed.
If I were to do this, I would probably make a user nginx with UID 100.
But I respect @dol's desire to have a common nginx file. But could you use user nobody instead? Or are you trying to have common nginx.conf files between between Nginx and OpenResty images?
I'm not going add a user to the image because the upstream packages do not do so.
If users want this, it is easy to include and control it in a derived image.
I'm labeling this a documentation bug -- we can show how to do this.
I am revisiting this because of some HackerNews discussion about bunkerized-nginx)[https://news.ycombinator.com/item?id=24842306] .... putting notes here.
-
There is now a
docker-nginx-unprivilegedimage which creates annginxuser with a specificuid -
We can support arbitrary UIDs as a build arg so users can specify for their own environment (OpenShift link,
bunkerized-nginxissue.
Hello. Just for the record, user nobody doesn't seem to work with openresty:buster (not sure about the other flavors):
nginx: [emerg] getgrnam("nobody") failed in /usr/local/openresty/nginx/conf/nginx.conf:1
Any plans to revisit an unprivileged user like with docker.io/nginxinc/nginx-unprivileged ? I assume that would be more secure...
I don't have specific plans, but since you pinged and 'tis the season, I just re-visited it.
As a first step, I'll create a -alpine-apk-unpriv and -bullseye-unpriv, applying the bullet points from the docker-nginx-unprivileged README. I have no stats on what anybody actually uses (but >50M pulls now, it said >10M for a long time!).
Like docker-nginx-unprivileged, we'd default to user nginx and 101 and create the users and inject the user nginx; directive.
I think that will work -- any feedback?
How can I add non-root user to Dockerfile for image/version "FROM openresty/openresty:stretch"? can anybody suggest/answer the command for the same?
@shyam-prajapat I don't plan on adding the support in this ticket to stretch, but here's the rough cut:
- add
user nginx;tonginx.conf(or whatever username you want) - create the user in the container with whatever UID/GID
- make sure relevant files mounted / accessed are readable/writable by that UID/GID
I'm not going add a user to the image because the upstream packages do not do so.
If users want this, it is easy to include and control it in a derived image.
I'm labeling this a documentation bug -- we can show how to do this.
To follow up on the documentation: Could you provide a link to where running openresty as non-root is described?
I understand that some of it may be described in this thread, but it would be great if there was a more comprehensive writeup, perhaps featuring an example Dockerfile to copy from...
Hello, Here a sample DockerFile that will run openresty as appuser
FROM openresty/openresty:1.21.4.3-1-alpine-apk
RUN addgroup --gid ${GID:-101} appuser && adduser --uid ${UID:-101} -G appuser --disabled-password --gecos "" appuser
COPY docker-entrypoint.sh /
RUN ["chown", "-R", "appuser:appuser", "/usr/local/openresty/nginx"]
RUN ["chmod", "+rx", "/docker-entrypoint.sh"]
EXPOSE 8443
USER appuser
ENTRYPOINT [ "/docker-entrypoint.sh" ]
(edit) you can remove the ENTRYPOINT. My entrypoint analyze environments variables to update some configuration file, and then launch :
/usr/local/openresty/bin/openresty -g "daemon off;" which is the default command
I am doubtful about its security implications, if we run as a non-root user then both nginx master / worker processes run with that same user.
This means that the worker processes also have the access to things that only master needs access to. This becomes worse when for instance you mount ssl certs/keys, these must be readable to the master nginx process, and in this case even the worker processes will be able to see those keys/certs
If instead we run master process as root and specify a non-root user in nginx conf, we can grant that user absolutely minimal permission.
I am using rootless docker with the second approach btw. Don't know if its more secure, but definitely do not like the idea of having worker processes with read access to SSL keys..
