Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not possible anymore to run as non-root #602

Open
MathiasVDA opened this issue Dec 12, 2023 · 12 comments
Open

Not possible anymore to run as non-root #602

MathiasVDA opened this issue Dec 12, 2023 · 12 comments

Comments

@MathiasVDA
Copy link

Feature description

We use geoserver on openshift and that requires to run with a random user id but with group id=0. In general, it's not advised to run containers as root. It used to be the case, after closing this merge request: #195 that your image allowed to run as non-root. However, now there are many mkdir, groupadd, useradd, chown, ... commands executed in the entrypoint scripts that don't allow to run as anything other then root anymore.

Additional context

Run as non root means that you can startup your container with:

docker run -it -e GROUP_NAME=0 -e GEOSERVER_GID=0 -u 12345:0 geoserver-test kartoza/geoserver

@NyakudyaA
Copy link
Collaborator

@MathiasVDA What is the issue, running as root you will need to execute

-e RUN_AS_ROOT=TRUE

But by default the container runs as a none-root. If you still need the PR to be restricted you can reopen it and make the adjustments and we can review it

@MathiasVDA
Copy link
Author

If you still need the PR
The PR is not relevant anymore since too many changes have been made requiring more and more rights.

But by default the container runs as a none-root.
The container doesn't run as non root by default. When you start a vanilla image docker run kartoza/geoserver, log into the container and execute the whoami command, you'll see you are running as root:
image

running as any other user docker run -u 12345:0 kartoza/geoserver will result in errors (that will prevent running the image on openshift):

groupadd: Permission denied.
groupadd: cannot lock /etc/group; try again later.

The above errors can be solved by modifying the docker command in this way:
docker run -it -e GROUP_NAME=0 -e GEOSERVER_GID=0 -e USER=root -u 12345:0 kartoza/geoserver

But that will then result in other issues:

mkdir: cannot create directory ‘/opt/geoserver’: Permission denied
mkdir: cannot create directory ‘/etc/certs’: Permission denied
mkdir: cannot create directory ‘/opt/footprints_dir’: Permission denied
mkdir: cannot create directory ‘/opt/fonts’: Permission denied
mkdir: cannot create directory ‘/opt/geoserver’: Permission denied
mkdir: cannot create directory ‘/settings’: Permission denied

If you want to be able to really run as non-root, you'll need to modify the Dockerfile so that it executes all the commands that would otherwise be done during container initiation.

Note: you might be running the geoserver deamon as non-root, but that doesn't mean that the container initiation is also done in non-root.

@NyakudyaA
Copy link
Collaborator

If you still need the PR
The PR is not relevant anymore since too many changes have been made requiring more and more rights.

But by default the container runs as a none-root.
The container doesn't run as non root by default. When you start a vanilla image docker run kartoza/geoserver, log into the container and execute the whoami command, you'll see you are running as root:
image

running as any other user docker run -u 12345:0 kartoza/geoserver will result in errors (that will prevent running the image on openshift):

groupadd: Permission denied.
groupadd: cannot lock /etc/group; try again later.

The above errors can be solved by modifying the docker command in this way: docker run -it -e GROUP_NAME=0 -e GEOSERVER_GID=0 -e USER=root -u 12345:0 kartoza/geoserver

Why specify user as root, this will cause issues. The point of running as non-root is to allow you to specify another user which is not root. So during container start 2 things are happening

  1. Run setup files as root
  2. Chown files and folder to the user specified by env variables

But that will then result in other issues:

mkdir: cannot create directory ‘/opt/geoserver’: Permission denied
mkdir: cannot create directory ‘/etc/certs’: Permission denied
mkdir: cannot create directory ‘/opt/footprints_dir’: Permission denied
mkdir: cannot create directory ‘/opt/fonts’: Permission denied
mkdir: cannot create directory ‘/opt/geoserver’: Permission denied
mkdir: cannot create directory ‘/settings’: Permission denied

If you want to be able to really run as non-root, you'll need to modify the Dockerfile so that it executes all the commands that would otherwise be done during container initiation.

I am against this because it hardcodes the users etc and will force everyone to chown their folders to be owned by that specific user before running. The current system works in a better way as it allows users to pass userid and groupid and this are used in the initi process. If you have any other suggestions.

Note: you might be running the geoserver deamon as non-root, but that doesn't mean that the container initiation is also done in non-root.

@MathiasVDA
Copy link
Author

Openshift will run containers with a random user (which can be simulated with the -u flag in docker run). There is no possibility to define the user as an environmental variable in the docker run command.

Openshift will also not allow to run the setup files as root.

I am against this because it hardcodes the users
But now you force users to use root to start the container

Sorry I don't want to interfere in what is really a great opensource project. It was my purpose to try to improve this project but I now realise that not everyone might see my suggestion as an improvement. Which is absolutely fine. I will close this issue and try to find another method to run geoserver on our openshift cluster.

@NyakudyaA NyakudyaA reopened this Dec 14, 2023
@NyakudyaA
Copy link
Collaborator

@MathiasVDA We are not against your suggestions but we need to make sure that when you incorporate them they still also work for a standard installs like vanilla Ubuntu, popOS etc.

I think in your previous PR that was closed you could resurrect it but have an if condition in entrypoint that could test the architecture i.e https://github.com/kartoza/docker-geoserver/blob/develop/scripts/setup.sh#L89

We have no much experience with open shift. So rather reopen the old PR, make improvements and we can take it from there in the code review. If you remember the previous PR was closed on the assumption that it was now working.

Another alternative would be to figure out how we could publish the images mainly geared for openshift. I am sure there are actions to do this

@Rezorl
Copy link

Rezorl commented Jan 29, 2024

Openshift will run containers with a random user (which can be simulated with the -u flag in docker run). There is no possibility to define the user as an environmental variable in the docker run command.

Openshift will also not allow to run the setup files as root.

I am against this because it hardcodes the users
But now you force users to use root to start the container

Sorry I don't want to interfere in what is really a great opensource project. It was my purpose to try to improve this project but I now realise that not everyone might see my suggestion as an improvement. Which is absolutely fine. I will close this issue and try to find another method to run geoserver on our openshift cluster.

@MathiasVDA Any news? Have you found the solution?

@MathiasVDA
Copy link
Author

MathiasVDA commented Jan 29, 2024

@MathiasVDA Any news? Have you found the solution?

@Rezorl yes, we have created our own dockerfile and startup script based on docker.osgeo.org/geoserver

The docker.osgeo.org/geoserver also has issues with running the container as nonroot

The dockerfile mainly:

  • copies scripts
  • sets some variables (for example where to put the geoserver data)
  • installs extensions
  • sets the proper rights for the nonroot user

The entrypoint script mainly:

  • names the nonroot user
  • continues what the docker.osgeo.org/geoserver normally does

@Rezorl
Copy link

Rezorl commented Jan 29, 2024

@MathiasVDA Any news? Have you found the solution?

@Rezorl yes, we have created our own dockerfile and startup script based on docker.osgeo.org/geoserver

The docker.osgeo.org/geoserver also has issues with running the container as nonroot

The dockerfile mainly:

  • copies scripts
  • sets some variables (for example where to put the geoserver data)
  • installs extensions
  • sets the proper rights for the nonroot user

The entrypoint script mainly:

  • names the nonroot user
  • continues what the docker.osgeo.org/geoserver normally does

@MathiasVDA Thanks. Could you show what the changed/added files look like?

@MathiasVDA
Copy link
Author

@MathiasVDA Thanks. Could you show what the changed/added files look like?

@Rezorl Sure, here it is: https://gitlab.com/mathias.vanden.auweele/geoserver-openshift

@Rezorl
Copy link

Rezorl commented Jan 31, 2024

@MathiasVDA Thanks. Could you show what the changed/added files look like?

@Rezorl Sure, here it is: https://gitlab.com/mathias.vanden.auweele/geoserver-openshift

It works. Thank you.

@mdprev
Copy link

mdprev commented May 22, 2024

Thanks for taking the time to write up this issue @MathiasVDA. I tried upgrading our Kartoza OpenShift deployment a while back and also saw the breaking changes in the entrypoint scripts. You summarized the issues nicely.

@NyakudyaA
Copy link
Collaborator

@mdprev @MathiasVDA Coming back to the issue again. It seems like the container runs as root but the tomcat instance runs as the specific user that is defined, According we are using gosu to step down from running tomcat as root with https://github.com/tianon/gosu.

How about having the following options:

  • Have a directory with scripts that are directly geared and have options for openshift , we could have an action that publishes this and tag the images accordingly. Note I have no openshift deployment to test this with.
  • You do a PR with your changes and we try to make sure that they still also work on other distros. This would be my preferred option

The main goal here is to have non root containers as it poses security risks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants