Adding new Container and Container.debian dockerfiles to enable rootl… #8
Conversation
…ess server mode. The debian package is preffered for systems using FIPS mode, I.E RHEL9 in FIPS mode, as the openssl version breaks apt and SSL cert generation. However, when using debian directly, the the certificates are created without issue.
openvoxserver/Containerfile
Outdated
|
|
||
| USER puppet | ||
|
|
||
| RUN mkdir -p /home/puppet/.puppetlabs/etc/ && \ |
There was a problem hiding this comment.
why exactly is this required? Without the container, puppetserver is also started as puppet user.
There was a problem hiding this comment.
I am not sure I follow what you mean by "Without the container".
The main issue is that the ENTRYPOINT and CMD within container is RAN by root, it assumed all of the ROOT ENV and puppet config variables in the deployment scripts within /docker-entrypoint.d. This is easy to see:
Lets use your container:
podman run -itd --replace --name openvox --hostname openvox --entrypoint bash ghcr.io/openvoxproject/openvoxserver:8.8.0-latest
And now lets get a shell inside the container and see who the container is running as:
podman exec -it openvox bash
root@openvox:/# whoami
root
This is a security issue. The containers user should be a non-root user. If this container was to run in Openshift or Rancher Carbide, it would be immediately rejected.
Similarly lets look at the new container builds..
podman run -itd --replace --name openvox --hostname openvox --entrypoint bash openvoxserver:debian
podman exec -it openvox bash
puppet@openvox:~$ whoami
puppet
Excellent... this would run without warnings or issues in Rancher Carbide or Openshift.
SOOO... looking at the issue we need to solve when using USER puppet.
When using root:
#podman exec -itd openvox bash
#puppet config print
agent_catalog_run_lockfile = /opt/puppetlabs/puppet/cache/state/agent_catalog_run.lock
agent_disabled_lockfile = /opt/puppetlabs/puppet/cache/state/agent_disabled.lock
allow_duplicate_certs = false
allow_pson_serialization = false
always_retry_plugins = true
autoflush = true
autosign = /etc/puppetlabs/puppet/autosign.conf
basemodulepath = /etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules
binder_config =
bucketdir = /opt/puppetlabs/puppet/cache/bucket
ca_fingerprint =
ca_name = Puppet CA: openvox.core.gtri.org
ca_port = 8140
ca_refresh_interval = 86400
ca_server = puppet
ca_ttl = 157680000
cacert = /etc/puppetlabs/puppetserver/ca/ca_crt.pem
cacrl = /etc/puppetlabs/puppetserver/ca/ca_crl.pem
cadir = /etc/puppetlabs/puppetserver/ca
cakey = /etc/puppetlabs/puppetserver/ca/ca_key.pem
capub = /etc/puppetlabs/puppetserver/ca/ca_pub.pem
catalog_cache_terminus =
catalog_terminus = compiler
cert_inventory = /etc/puppetlabs/puppetserver/ca/inventory.txt
certdir = /etc/puppetlabs/puppet/ssl/certs
certificate_revocation = chain
...
Versus non-root. The puppet user has UID 999
#podman exec -it --user 999 openvox bash
$ puppet config print
puppet@openvox:/$ puppet config print
agent_catalog_run_lockfile = /opt/puppetlabs/server/data/puppetserver/.puppetlabs/opt/puppet/cache/state/agent_catalog_run.lock
agent_disabled_lockfile = /opt/puppetlabs/server/data/puppetserver/.puppetlabs/opt/puppet/cache/state/agent_disabled.lock
allow_duplicate_certs = false
allow_pson_serialization = false
always_retry_plugins = true
autoflush = true
autosign = /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/puppet/autosign.conf
basemodulepath = /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/code/modules:/opt/puppetlabs/puppet/modules
binder_config =
bucketdir = /opt/puppetlabs/server/data/puppetserver/.puppetlabs/opt/puppet/cache/bucket
ca_fingerprint =
ca_name = Puppet CA: openvox.core.gtri.org
ca_port = 8140
ca_refresh_interval = 86400
ca_server = puppet
ca_ttl = 157680000
cacert = /etc/puppetlabs/puppetserver/ca/ca_crt.pem
cacrl = /etc/puppetlabs/puppetserver/ca/ca_crl.pem
cadir = /etc/puppetlabs/puppetserver/ca
cakey = /etc/puppetlabs/puppetserver/ca/ca_key.pem
capub = /etc/puppetlabs/puppetserver/ca/ca_pub.pem
catalog_cache_terminus =
catalog_terminus = compiler
cert_inventory = /etc/puppetlabs/puppetserver/ca/inventory.txt
certdir = /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/puppet/ssl/certs
certificate_revocation = chain
So in the default container, the puppet user (UID - 999) has a HOME directory set as /opt/puppetlabs/server/data/puppetserver, and looking at the puppet documentation:
https://www.puppet.com/docs/puppet/8/dirs_confdir.html#dirs_confdir-confdir-location
Non-root users: ~/.puppetlabs/etc/puppet
This change in the path, really screws up the ENTRYPOINT and CMD init using:
/docker-entrypoint.sh and /docker-entrypoint.d/
Because of this, I KNOW where things will change to automatically when I use a non-root user to run the ENTRYPOINT/CMD, so I leverage this and link it to the default deployment.
There was a problem hiding this comment.
Also... it is important to make the mounts simple, or keep them the same, as we need to give the end users an easy way to preserve the CA folder for certificates.
By using the symlink method, the container can still easily mount:
-v ./CA/:/etc/puppetlabs/puppet/ssl/ca/
VERSUS
-v ./CA/:/home/puppet/.puppetlabs/etc/puppet/ssl/ca
| @@ -68,6 +68,7 @@ ENV OPENVOXSERVER_JAVA_ARGS="-Xms1024m -Xmx1024m" \ | |||
| OPENVOXSERVER_ENABLE_ENV_CACHE_DEL_API=true \ | |||
| ENVIRONMENTPATH=/etc/puppetlabs/code/environments \ | |||
| HIERACONFIG='$confdir/hiera.yaml' \ | |||
| HOME=/home/puppet \ | |||
There was a problem hiding this comment.
in the deb/rpm packages, it's /opt/puppetlabs/server/data/puppetserver
There was a problem hiding this comment.
It doesnt matter if the HOME directory is
/opt/puppetlabs/server/data/puppetserver
or
/home/puppet
because it will still be interpolated as
/opt/puppetlabs/server/data/puppetserver/.puppetlabs/....
or
/home/puppet/.puppetlabs/...
I simply felt that /home/puppet/.puppetlabs/... looks a lot cleaner. One could just as easily setup the SYMLINK for the opt folder as well, simply by changing this:
RUN mkdir -p /home/puppet/.puppetlabs/etc/ && \
ln -s /etc/puppetlabs/puppet/ /home/puppet/.puppetlabs/etc/puppet
`
There was a problem hiding this comment.
Actually this can get simpler
RUN mkdir -p /home/puppet/.puppetlabs && \
ln -s /etc/puppetlabs /home/puppet/.puppetlabs/etc
However CADIR for a non-root user is set to:
cadir = /home/puppet/.puppetlabs/etc/puppet/ssl/ca
Which conflicts that it should be /etc/puppetlabs/puppetserver/ca.
Also, I need to do a similar link for the OPT and VAR folders.
There was a problem hiding this comment.
This should be fixed. I added a similar symlink to /opt.
I also fixed the incorrect non-root CA dir by adding:
puppet config set cadir /etc/puppetlabs/puppetserver/ca/
There was a problem hiding this comment.
I'm just wondering why this is required at all. When systemd starts the normal puppetserver unit, it does that as puppet user, but it doesn't look for configs in its home.
There was a problem hiding this comment.
Systemd doesn't exist in the container.
I dont have a puppetserver in front of me. But I would guess it's because the service runs as root.
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#User=
And I'm guessing the environment in this case is setup for root, not puppet, even though the binaries are being ran as puppet.
I'm willing to bet if you actually ssh'd into a server as a non root user and ran the systemd unit without sudo (you would have to use the --user flag https://wiki.archlinux.org/title/Systemd/User) it would be a different story.
I don't think config files should be owned by the user running it. There's no benefit and only a risk. At most you'd chgrp them and use mode 0640.
This comes from https://github.com/puppetlabs/puppet/blob/e227c27540975c25aa22d533a52424a9d2fc886a/lib/puppet/util/run_mode.rb#L49-L64 But I wonder how puppetserver works in systemd because there it runs as non-root and still uses root paths. I think it's this code that forces it: So perhaps the solution is to make sure the process starts with |
There was a problem hiding this comment.
Why a new file? Can't you use an argument for the base container just like UBUNTU_VERSION is now an arg?
There was a problem hiding this comment.
The repo URL is a bit different. To me it makes since to separate out the files.
You would also need an OS argument for:
ADD https://apt.overlookinfratech.com/openvox${OPENVOX_RELEASE}-release-debian${DEBIAN_VERSION}.deb
But you could do that and have a single file if desired.
I don't think changing the group to puppet with read only will work. The container's entrypoint runs as puppet. And this is a long series of commands, including ones to generate CA certs, moving files, setting up puppetserver, etc....so all those files need to have the puppet user have the ability to read and write them. But it's still safer to run the service as puppet, instead of root as far as containers go. I couldn't find way to specify the location of a config file that didn't use 'confdir' which is read from a config file. That would definitely be much cleaner than the symlink, though the symlink seems to work quite well. I've done a good bit with containers, but not as much with puppet. So I would love if someone could tell me how to set a non-root users config location, without using a puppet.conf file. |
This is a pull request to hopefully add a rootless container build option.
#7
It might be wise to create three Containerfiles....
Containerfile - This one can be the original, rooted application.
Containerfile.debian - A debian deployment that runs as a non root user.
Container.ubuntu - An ubuntu deployment that runs as a non root user
The structure of the new Containerfiles is mostly unchanged, but with a few additions. And the deployment of the debian version versus ubuntu are also almost identical, except for using the debian repo into of the ubuntu repo.
NOTE
If someone is running a linux OS running FIPS mode, the Ubuntu container WILL NOT WORK. Openssl on ubuntu 24.04 is completely broken for FIPS mode and you will get ALGO errors when the certs are generated. The only method I found to solve this was to either add development or testing repos and install openssl 3.4, or compiling openssl by source. This got messy and I decided to not go this route as the debian container seems to run.
Major Changes:
(Debian Only) - Added DEBIAN_VERSION ARG, so that one can systematically reference/change the build. I.E:
ADD https://apt.overlookinfratech.com/openvox${OPENVOX_RELEASE}-release-debian${DEBIAN_VERSION}.debMajor permission changes - Since we are no longer running as root, we need to make sure that ALL the files required can be accessed by the puppet user:
(note - this could be simplified a bit if desired)
SYMLINK for non-root user - Puppet is configured in such a way that a non-root user's confdir, ssl and other directories are interpolated via the users HOME folder. This caused many issues in the build as the container was referencing paths such as:
/home/puppet/.puppetlabs/etc/...I decided the easiest way to fix this was actually to just use a simple SYMLINK:
This solved almost all of those problems. It allowed the same files to be referenced. However the container was still referencing the locations as
/home/puppet/.puppetlabs/etc/, So I made another change. I simply added aconfdirdirective in the puppet.conf. Since the puppet.conf located in/etc/puppetlabs/puppet/puppet/confis the same file as/home/puppet/.puppetlabs/etc/puppet/puppet.conf, the change was read and handled nicely.The container now seems to start correctly:
Which I run via a podman run command:
LASTLY - This is running, but I dont have an easy way to test adding an agent to it currently, so some assistance with testing would be helpful!