I am going on a adventure to try and better harden my containers and better isolate them from one another as well as the host server itself. I use IPVLAN and isolate my containers into VLANs based on 'activities'. For example: *arr stack is one VLAN, personal utilities (paperless or trillium notes is another VLAN, etc.

1. First question: Why can I not add VLANs to unRAID without having an IP address associated with it? The unRAID server itself doesn't need to have any presence on the VLAN for my *arr stack for example. The containers in the stack are isolated and firewalled off so I can only access them via a reverse proxy, but because unRAID puts an interface in that VLAN there are no firewall rules to stop it as it is layer 2. It seems like the docker engine 'blocks it' by I am not sure at what level it is blocked.

2. Are there any other best practices for host isolation? I have host access to custom networks disabled in my Docker settings. I don't have a single container that I run that should ever need access to unRAID directly, and I want to be sure it is 100% blocked otherwise.

3. I only run containers in br0.x on VLANs outside if the native VLAN for unRAID itself, so that should help as well.

4. Is it better to use custom docker networks, or use external VLANs for containers? I am much more comfortable using my external router/firewall, but if there is an inherent advantage to using Docker custom networks I can go that route as well.

5. I recently learned that Docker uses the DNS settings of the host by default, so I am also in the process of adding the --dns=x.x.x.x to all the containers that I don't wish to use my internal DNS server.

Looking for feedback, best practices and opinions on how to better harden my system and containers. There is a lot of trust in the FOSS community where we blindly trust run containers. As vibe coding becomes more and more common (thinking a bit about the Huntarr fiasco) I think a little hardening is a good idea.

you can use vlan in unraid and don't have an address on br0.x interface. You simply have to define ip assignment to none for the sub interface. But i guess in that case containers in that vlan can't use a bridge. I use it to define macvlan network.

One thing that came into my mind is that by default docker listen to all host interfaces so if you define a bridge in a vlan interface and you expose a port in a docker on another bridge you have to restrict listening interface when you define the bridge. It's done with the "com.docker.network.bridge.host_binding_ipv4" option in the bridge ipam driver.

custom networks bridge have the advantage of simplifying communication between containers. If you have several containers running in the same custom network they can communicate with each others by their name. For example if you have a server that need a database you can define the database host as postgres:5432

You can define firewall rules for your containers see docker docs (iptables).