Containerization Support

[jamilbk]

As mentioned in this Reddit comment, it would be useful to be able to run Firezone as a containerized application.

This presents us with a few challenges that need to be investigated, however:

• Firezone expects control of the host routing table to add default routes for the WireGuard interface and set up IPv4/IPv6 forwarding
• Firezone needs to be able to add a new nftables firewall and manage rules in that table
• Firezone needs to create a wireguard-type interface on the host and manage it

This StackOverflow post would be a good starting point.

This Arch Linux troubleshooting tip may be helpful as well: https://wiki.archlinux.org/title/nftables#Working_with_Docker

Edit: Perhaps this could be accomplished by abstracting the Firezone firewall driver so that eBPF can be used. This could open the door to integrate with something like https://github.com/cilium/cilium to provide eBPF-based filtering.

refs #737

[ABeltramo]

I'm sure you are aware of this already but there's also wg-easy which bundles Wireguard + a web UI on a Docker container.

I'm not sure why you'll need to modify the host routing table/iptables if you'll start firezone in the same container that starts wireguard too. Or maybe you are thinking of keeping wireguard on the host and just run firezone in a container?

[jamilbk]

@ABeltramo

I'm not sure why you'll need to modify the host routing table/iptables if you'll start firezone in the same container that starts wireguard too.

Firezone also acts as a simple frontend to nftables to block egress traffic, so we'd need a good way to achieve that from within a container.

[JohnFawkes]

Wouldn't using --net host solve these issues?

[Cediddi]

I'm using linuxserver/wireguard and I'd love to use firezone with that (or better, replace linuxserver/wireguard with firezone). That'd be amazing!

[sfxworks]

I would like to see this in Kubernetes as well, but that would come with containerization. If someone can wrap this in a container I'd test it with host networking.

[rchekhina]

HI,

I have tried to create a docker-compose of firezone but the problem I have is that firezone is using systemd to start the services and I wasnt able to change it because of the chef cookbooks.

[clementperon]

https://github.com/subspacecommunity/subspace run as network host + NET_ADMIN cap.

[jamilbk]

@clementperon Yeah, definitely possible. We'll be (hopefully) getting to this soon. The main hurdle is we have a whole systemd/chef-based configuration management system (Omnibus) that handles configuration, restarts, creating secrets, etc which is exposed through our firezone-ctl command, so need to create the equivalent for that in bash scripts and a docker-compose.yml services file, along with docs.

[craftyshaun]

@gongjason here's my 2c having built both ISPs and writing code.

Preface (I may be 100% wrong): I'm just learning containers and how they interact with the networks around them. But sometimes thinking of everything like a device in a rack helps me visualise the abstractions.

It all depends of your goals but I think of this similar to a cloudflared tunnel.

The container is 'the edge' between the VPN User and the Internal Network (the pod, the lan).

Currently firezone does a few things:

• Terminates Wiregard
• Provides a configuration GUI
• Routes traffic into and out of the wireguard

Its all about abstracting firezone so people can 'hook' the above where needed.

The TLDR :thinking:

The pod is 'the gateway / edge' between the networks

• The pod runs wireguard and the gui (similar to linuxserver/wireguard but with a gui)
• The pod exposes ports
• The above ports are exposed externally as nodeports
• These can be exposed using an ingress (L7 for 443, L3,L7 for UPD) (Nginx will route UDP)

Pod <-> k8 Network <-> Connected Networks (VPC and beyond)

• Once the traffic has left the pod its up to the Network Administrator do route it
• You could assist this by:
  • using eBPF
  • using BGP
  • using Nat

/cc @jamilbk @princemaple

[jamilbk]

@craftyshaun This is great. Thanks for the notes. Yeah @princemaple is working on dockerizing our dev environment first, then we'll work on production-izing it, then will be in a better place for a Helm chart I think.

We are planning to split the VPN termination and firewall apps out of the Phoenix web app to support multi-site in an upcoming release.

[alexanderadam]

Just to clarify: this solution will also work with Podman, right?

[princemaple]

Containerization technology is standardized. So hopefully yes. How convenient though, is a different story.

[MohammedNoureldin]

Any estimated milestone to finish Docker support? Or yet better K8s Helm Chart?

[jamilbk]

@MohammedNoureldin It's done, but we're still working on finalizing the documentation -- #961

If you're familiar with Docker you can get started today using the docker-compose.prod.yml file in the root of the repo, and use #887 as a guide for setting it up.

[JerboaGobi]

Just wanted to leave a big kuddos to your team. Maybe there is other solutions out there, none I could find, but when I initially started with Firezone I was seeking something that would support docker, WG, SSO, and MFA. At that time you didn't have the docker image on github but it was only a few weeks out. I've since dropped my requirement for SSO as the SSO service I was using isn't quite what I want. I'll likely end up implemented an SSO solution in the future, but that's an aside.

The container spun up without issue, well actually, I'm running arm64 and the python was missing at build, but you've since corrected that issue.

The product documentation is clear and concise. The docker deployment documentation wasn't as concise as it could be. Though due credit, the docker image isn't even published. Not going to fault you there; I'm sure once the image is published the docker documentation will be added on docs.firezone.dev. Without the product documentation I wouldn't have been able to get this deployed and working with reverse proxies, on it's own vlan, with HTTP headers forwarding, etc.

Again kuddos, great product. It looks like you've re-worked your licensing as well and the CE is now no longer limited to one user, that's great! I'm not using this commercially, just in the homelab and I'm thoroughly excited about having more than one user being able to connect.

[jamilbk]

Just wanted to leave a big kuddos to your team. Maybe there is other solutions out there, none I could find, but when I initially started with Firezone I was seeking something that would support docker, WG, SSO, and MFA. At that time you didn't have the docker image on github but it was only a few weeks out. I've since dropped my requirement for SSO as the SSO service I was using isn't quite what I want. I'll likely end up implemented an SSO solution in the future, but that's an aside.

The container spun up without issue, well actually, I'm running arm64 and the python was missing at build, but you've since corrected that issue.

The product documentation is clear and concise. The docker deployment documentation wasn't as concise as it could be. Though due credit, the docker image isn't even published. Not going to fault you there; I'm sure once the image is published the docker documentation will be added on docs.firezone.dev. Without the product documentation I wouldn't have been able to get this deployed and working with reverse proxies, on it's own vlan, with HTTP headers forwarding, etc.

Again kuddos, great product. It looks like you've re-worked your licensing as well and the CE is now no longer limited to one user, that's great! I'm not using this commercially, just in the homelab and I'm thoroughly excited about having more than one user being able to connect.

Thanks for the kind words. We are officially releasing Docker support in 0.6.0, coming any day now. Just wrapping up the last few PRs.