I was able to setup a linux bridge on my home network and able to have containers get a 192.168.xx IP address. This works well and seems to be the suggested approach outlined in the incus documentation for a single host.
I have also used a proxy device on the incus host to connect to a container.
Is there a use case and best practice for when you would use one over the other?
thanks
I use a linux bridge when I want to get connectivity across my LAN, e.g. instances for services used on my network; and I use the host-instance connectivity when I want the instance more isolated from my network, e.g. for WAN services. Not sure either is a “best practice”.
A Linux bridge exposes the whole container to the local network on a separate IP address. Whereas, a proxy device exposes a port of the container to a port on the host. You can setup a container with no networking at all, and still make it accessible through a proxy device! That last case would make an interesting honeypot.
The rule of thumb is that you try to give out as little exposure as necessary.
Thanks for the responses. I have generally been handling similar to how Andrew indicated in his post. I want to set up a reverse proxy using Traefik using a system container and see the following options:
Option 1- Setup firewall on the container to only allow ports 80 and 443 and expose the entire container on my network via the bridge
Option 2- Setup firewall on the container to only allow ports 80 and 443 and setup two proxy devices for ports 80 and 443 from my incus host.
Interested in any thoughts between the two options. With a firewall in place, is option 2 really more secure?
Simos- I have also seen some of your older blogs on setting a container with multiple interfaces. I think my Traefik reverse container will need access to multiple networks as some of my containers will be exposed to the internet and some will be private. Not sure if setting up two instances of Traefik (external and intermal) would be a better option.
Since Traefik would be exposed to the internet I would want to harden this container as much as possible.
As @simos mentioned using proxies is a bit more secure than having the full container exposed to the network.
For a reverse proxy you mainly only need the two ports 80/443 exposed and that’s it. Sometimes there are other services on the container like an admin port or similar which you won’t expose. Using the proxy approach keeps things simple/hidden. You can for example also use non default ports on the private container and proxy to them.
In general I think using containers on a private bridge offers more flexibility compared to exposing them directly to the network. At the end the choice is yours what might be better and more secure.
Thanks- I appreciate your response.
You should be able to make two reverse proxies to work with each other, if that is suitable for your use-case (front reverse-proxy and two back reverse-proxies). The only difficulty should be with the PROXY protocol and how to preserve the client IP (or no, if you want easy GDPR compliance as a side-effect 
).
Such a setup would be a very good exercise in going deep into reverse-proxies. It’s somewhat difficult to find resources because proxy chaining will bring up articles about proxychains (not relevant; this one hooks into dynamic libraries) and how to chain multiple anonymizing proxies for added anonymity.