apisix-docker
apisix-docker copied to clipboard
feature request/security: avoid container running root
Hey there,
In advance, thanks for your time and help.
Context
I was trying to make Apisix run in a OpenShift cluster but without having root running the container. To do so I am using the official upstream Helm chart. I was able to run everything but the Apisix deployment without root.
A work around is to use the SCC as anyuid on the service account running the application to let the application run as user root (0). Obviously in a perfect world we do not want that.
That is why I am asking if that would be possible to make the application run as a non-root user. When trying this solution with the help of the Helm chart, and without setting up the SCC I am getting this error below:
/usr/local/openresty/luajit/bin/luajit ./apisix/cli/apisix.lua init failed to update nginx.conf: failed to open file: /usr/local/apisi/conf/nginx.conf, error info:/usr/local/apisix/conf/nginx.conf: Permission denied
The error makes total sense, as the generated nginx configuration has those permissions:
bash-5.1# ls -la /usr/local/apisix/conf/nginx.conf
-rw-r--r-- 1 root root 11422 Jul 5 10:49 /usr/local/apisix/conf/nginx.conf
Solutions
The first easy solution would be to add write access to the group root on this file as every container is started with the root group (0) on OpenShift. The nginx configuration seems to be generated somehow, maybe it would be doable to add the write permission to the group on the fly?
The second one is a bit more tricky and might require more work but would simply follows the Best practices for writing Dockerfiles. Again maybe we have a application limitation, but I think that should be feasible!
Please let me know if something is unclear or not understood here.
Thanks for evaluating this proposition of a new feature to gain a bit of flexibility and security while running Apisix.
The first easy solution would be to add write access to the group root on this file as every container is started with the root group (0) on OpenShift. The nginx configuration seems to be generated somehow, maybe it would be doable to add the write permission to the group on the fly?
Yes, the nginx.conf is generated when APISIX just starts. We may add the write and execute permission for the path /usr/local/apisix/conf.
Yes, the
nginx.confis generated when APISIX just starts. We may add the write and execute permission for the path/usr/local/apisix/conf.
Right, your suggestion is nice and it would be awesome if you could implement this feature. Thanks for your effort here!
Yes, the
nginx.confis generated when APISIX just starts. We may add the write and execute permission for the path/usr/local/apisix/conf.
we can do this in Dockerfile?
Yes, the
nginx.confis generated when APISIX just starts. We may add the write and execute permission for the path/usr/local/apisix/conf.we can do this in Dockerfile?
I think so.
This issue has been marked as stale due to 30 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.
@tzssangglass @tokers any news?
someone work on this:https://github.com/apache/apisix-docker/search?q=root+is%3Apr&type=issues, but no one seems to be pushing it to master eventually.
Any new status on that?
This issue has been marked as stale due to 30 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.
ping :}
someone work on this:https://github.com/apache/apisix-docker/search?q=root+is%3Apr&type=issues, but no one seems to be pushing it to master eventually.
@vmaillot Is this OK for you?
someone work on this:https://github.com/apache/apisix-docker/search?q=root+is%3Apr&type=issues, but no one seems to be pushing it to master eventually.
@vmaillot Is this OK for you?
well, can't this be pushed to master somehow?
hi, i will do it @vmaillot
hi, i will do it @vmaillot
hey @Hazel6869 thanks a lot! it is much appreciated
This issue has been marked as stale due to 30 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.
@Hazel6869 any progress on your side regarding #371?
@vmaillot I'm testing. sorry~ I want to know which image is you used,

@vmaillot I'm testing. sorry~ I want to know which image is you used,
hey @Hazel6869 sorry for the late reply, but i would suggest to go with alpine : D lightweight ftw!
APISIX has stopped maintaining the alpine image, it is recommended that you use debian.
@vmaillot sorry, APISIX has stopped maintaining the alpine image, it is recommended that you use debian. how do you think.
@vmaillot sorry, APISIX has stopped maintaining the alpine image, it is recommended that you use debian. how do you think.
@Hazel6869 debian would be totally fine! thanks for checking
@vmaillot OK, I will use debian, I have time today, I will fix it.
Does this change need to be applied to centos based image? and also, this may required some more docs, non root user can not bind ports under 1024, unless use securityContext.runAsUser to override the default user.
Finally, I found cause that I can't bind ports 80 and 443. Release 3.1.0 is the first release that contain this change, right? This affect helm chart too. Have to add securityContext.runAsUser=0 (run as root).
Finally, I found cause that I can't bind ports 80 and 443. Release 3.1.0 is the first release that contain this change, right? This affect helm chart too. Have to add securityContext.runAsUser=0 (run as root).
@Hazel6869 Please take a look when you have time.
From an Helm chart point of view, why did you guys reverted to use 2.15.1-debian image?
Thanks for your time and help!
Chart 1.x is for Apisix v3. Chart 0.x is for Apisix V2.
@ankworld The helm chart version 0.12.3 contains / referencing the apisix 3.1.0-debian image. So the question above was valid. https://github.com/apache/apisix-helm-chart/blob/apisix-0.12.3/charts/apisix/values.yaml#L84
This was fixed in the chart 0.13.0: https://github.com/apache/apisix-helm-chart/blob/apisix-0.13.0/charts/apisix/values.yaml#L84
Also this means that that the non-root (current thread tema) changes are no incorporated in the 0.x chart version (apisix container image 2.x) only in the chart 1.x (apisix:3.1.0-debian)
From an Helm chart point of view, why did you guys reverted to use
2.15.1-debianimage?Thanks for your time and help! @vmaillot Hi,I don't understand, does the current change meet your needs?
This issue has been marked as stale due to 30 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.