Add docker based welcome.openstreetmap.org

[Firefishy]

Adds welcome.openstreetmap.org using a docker container service for the underlying website.

Apache is used to proxy requests to the container, but this could change in future.

The docker container service currently exposes a static external port (8090) to which apache proxies requests.

[tomhughes]

As far as I am concerned this should not deployed until we at least pretend to isolate the container from the host properly.

I'm happy to work up a way to do it properly with podman and other than that I suggest forgetting containerisation and just deploying the site on the host.

[Firefishy]

By default containers are isolated from the host unless running in the non-default privileged mode.

I have now moved the welcome-mat container to using port 8080 and an unprivileged user osmfoundation/welcome-mat@39abb40. The UID/GID is 101 as baked into the upstream image. I'm trying to avoid having to rebuild the full base image.

[tomhughes]

Is community running in privileged mode then? Because it definitely does not have proper user isolation...

[Firefishy]

Is community running in privileged mode then? Because it definitely does not have proper user isolation...

No, the community service runs in docker's concept of underprivileged, but the container does launch as a containerised "root" user (which isn't ideal) and then within the container SETUIDs to other underprivileged users per discourse's own design.

I'd prefer to deal with any discourse docker issues separately to this issue. The https://github.com/discourse/discourse_docker setup is indeed not sane in my view. I am watching this alternative build closely and waiting for v3.0.x https://bitnami.com/stack/discourse/containers

The discourse run command is crazy:
docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=32 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=data -e DISCOURSE_DB_PORT= -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_FORCE_HTTPS=true -e DISCOURSE_HOSTNAME=community.openstreetmap.org -e DISCOURSE_CDN_URL=https://community-cdn.openstreetmap.org -e [email protected] -e DISCOURSE_SMTP_ADDRESS=mail.openstreetmap.org -e DISCOURSE_SMTP_PORT=26 -e DISCOURSE_SMTP_OPENSSL_VERIFY_MODE=none -e DISCOURSE_SMTP_USER_NAME= -e DISCOURSE_SMTP_PASSWORD= -e DISCOURSE_SMTP_DOMAIN=community.openstreetmap.org -e [email protected] -e DISCOURSE_DB_PASSWORD=SECRET -e DISCOURSE_REDIS_HOST=data -e DISCOURSE_MAXMIND_LICENSE_KEY=SECRET -h jakelong-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /srv/community.openstreetmap.org/shared/web-only:/shared -v /srv/community.openstreetmap.org/shared/web-only/log/var-log:/var/log -v /etc/ssl/certs/community.openstreetmap.org.pem:/shared/ssl/ssl.crt -v /etc/ssl/private/community.openstreetmap.org.key:/shared/ssl/ssl.key --mac-address 02:3e:60:7f:73:95 local_discourse/web_only /sbin/boot

[tomhughes]

I'm not trying to resolve the discourse issues here but I am trying to make sure that this PR doesn't introduce the same problems for welcome-mat and I just checked and it does... I ran up the test in kitchen then logged in to the test container, which is the host as far as welcome-mat is concerned, and ran pstree on the welcome-mat entry point process:

root@dokken:/# pstree -u 10314
containerd-shim-+-nginx(systemd-network)---64*[nginx]
                `-10*[{containerd-shim}]

So all the nginx processes in the container are running as the host's systemd-network user which means if they manage to access the host filesystem in any way, or any other host resources which are subject to control based on uid, then they will be able to access network management related things!

[tomhughes]

By comparison here's what happened when I did podman run --rm -it ghcr.io/osmfoundation/welcome-mat:latest and then looked at the process tree:

% pstree -u 2314993
conmon(tom)───nginx(100100)───64*[nginx]

The nginx processes are safely isolated as a new user. In a real production deployment I would use a service unit with DynamicUser=yes so that even the top level conmon was running a unique user to that service.

[Firefishy]

So all the nginx processes in the container are running as the host's systemd-network user which means if they manage to access the host filesystem in any way, ...

Now amended to use www-data : www-data UID/GID.

Using full DynamicUser=yes or similar with podman could likely be a future step.

[tomhughes]

Does --user 33:33 actually do anything at all? That's basically what happens by default unless it also changes what happens to users other than 33?

Presumably you also changed the container to use 33 because it was using 101 or something I think?

It's horribly fragile though as you're assuming the meaning of 33 on both sides.

I haven't quite finished it but I spent much of last night working on doing this better. Hopefully have something later.

[Firefishy]

Yes --user 33:33 changes the UID/GID the container and processes within uses. 33 UID/GID is an Ubuntu/Debian standard for www-data and is unlikely to change. --user www-data:www-data (dynamic lookup) also works, but would require me to move around the apache install (which creates www-data) to before the container service is created and started.

The upstream https://hub.docker.com/r/nginxinc/nginx-unprivileged container is happy to run as any UID/GID combination because it only uses /tmp within the container for ephemeral storage.