Secure, configurable CUPS container and setup instructions

[agritheory]

Container should include:

• CUPS
• Most common printer libraries
• Exposed CUPS Web GUI
• TLS probably requires a Reverse Proxy (preferably Caddy) but may require some secure tunneling protocol
• Bonjour or other appropriate mDNS / discovery service for printers

[agritheory]

@batonac Has provided some details about his Cloudflare config:

Update on the cups/cloudflared discussion. I had to implement this again today, and like you, struggled to get remote auth working correctly. I'm starting to conclude that cloudflared doesn't support basic HTTP authentication, which is why this is so difficult with cups. Fortunately, there is a pretty simple and slick workaround. Just set up a zero-trust "application" in cloudflare which enforces authentication for specific users only for any cups admin pages.

These cloudflared ingress rules work really well for spoofing cups to believe that we're connecting locally:

- hostname: cups.clientdomain.com
service: https://127.0.0.1:631/
originRequest:
noTLSVerify: true
httpHostHeader: localhost
- hostname: ssh.clientdomain.com
service: ssh://127.0.0.1:22
- service: unix:/run/nginx.sock

And an application policy in cloudflare can be configured for only certain users like this.

The actual application is configured like so.

[lucasvazq]

Good morning @agritheory !

I had been having some trouble implementing my service with caddy and adding certbot to it. More specifically, certbot is that it had given me a couple of problems. I was finally able to do it.

Here you'll find an open PR in a fork that has the code I've developed to date: https://github.com/agritheory/beam/pull/79 All this code, available inside the cups folder, is up on a Digital Ocean Droplet (VM) that I generated just for testing. The site is certified and automatic site renewal is enabled: https://test7432.duckdns.org/ If you are interested in accessing the VM console, PM me a public key so I can add you and pass you the IP.

To solve the issue, I would need to check a few things: 1) Adapt the code to use podman instead of docker. ✅ 2) Check the cups configurations and the user/password definition. ✅ 3) Add Bonjour. Luckily for me, someone has already implemented this service, so I already have a place to explore: https://github.com/SickHub/docker-cups-airprint 4) Occasionally I get the error "Request Entity Too Large".

I have a doubt. When you mention "secure tunneling protocol" do you mean that you would like a secure connection between Caddy and Cups? If so, in the current implementation this is not necessary. The Cups container is exposed internally on an internal network of the container, both the Cups service and the network are inaccessible from the outside. It is the Caddy service, which also belongs to this network, which is exposed.

[agritheory]

@lucasvazq

I had been having some trouble implementing my service with caddy and adding certbot to it. More specifically, certbot is that it had given me a couple of problems. I was finally able to do it.

There shouldn't be any need to integrate Certbot AND Caddy - Caddy does certs automatically without a Certbot dependency.

I have a doubt. When you mention "secure tunneling protocol" do you mean that you would like a secure connection between Caddy and Cups?

No, this would an alternative to using Caddy or nginx + Certbot. Since you have already implemented a Caddy-based solution, this alternative can be ignored.

[lucasvazq]

Hello Tyler!! @agritheory

I installed Avahi (a Bonjour alternative for Linux) inside the container and have been trying to test it on my PC. Since I didn't have a printer, I tried with a fake printer but didn't get good results. The repository has 2 ways to configure, and in the README they are both: with Docker and with Podman. Why both? To adapt to different needs (my pc does not support podman for example). Having the 2 versions did not cost time, since both technologies have a similar syntax.

[agritheory]

I installed Avahi (a Bonjour alternative for Linux) inside the container and have been trying to test it on my PC. Since I didn't have a printer, I tried with a fake printer but didn't get good results.

I have a local printer and will test.

The repository has 2 ways to configure, and in the README they are both: with Docker and with Podman. Why both? To adapt to different needs (my pc does not support podman for example). Having the 2 versions did not cost time, since both technologies have a similar syntax.

Docker is the container of choice for software developers because of its flexibility and ease of use but it is less secure by default than Podman. Docker (the company) has never been profitable and does not have a path towards being profitable, so it seems very likely to me they will be aquired by someone who can monetize their technology and I think that more than half the candidates have a bad track record there (Oracle, IBM, etc). So despite Podman being less well known, I believe it is a better long term bet, especially for production deployments.