This is the second part in my series of blog entries on designing an eBrainPool Linux Container that follows objectives I outlined in my previous post Building the eBrainPool Linux Container - Part 1
Design 2 - Unique network bridge for container
Maximum security with minimum complexity - this is the goal for our sandbox. Our earlier design failed on the complexity front because it needed a bridge on the host to which we would add the network interface of interest for eBrainPool. Not a trivial change and could disrupt and/or degrade performance on the host. The key elements in the design proposed above are :
-
a unique bridge for the container. The host interface is not added to this bridge. The container is on it's unique private network that can be accessed only by the host.
-
the eBrainPool client runs within the container and is accessed on the host by ssh X forwarding from the container - as earlier the host's X server is isolated from the container.
-
Discovery is handled by Avahi for our client. Since the client is running in our container that is on a unique network segment we need avahi within the container. Avahi on the host needs a change in it's configuration that puts it in reflector mode.
-
The above allows eBrainPool clients to see each other via avahi, however each client is on it's own private segment. Only the host can access it's own container. Therefore for clients to communicate with each other a little jugglery is required. Clients need to make aware to each other the network address of the host they are on - not the container's ip (since that can't be accessed from anywhere but the host).
- The host then needs a port forwarding rule so that any client connecting to that port gets forwarded to the eBrainPool client in the container.
Improved security - yes. Complexity - high.
A root level change is needed to have an indepdendent bridge for the container. This is one time and can be done during package installation so this is acceptable.
It requires root access to implement changes in Avahi's configuration - putting it in reflector mode. How this affects other things on the host need to be thought of.
Change in code will allow the client to dissipate host IP instead of container IP - this is acceptable. However we also need a root level change on host to have a port forwarding rule put in for other clients to be able to access this. I like having an independent bridge for the container without tying in the host's network interface to this bridge. This is a big improvement over the earlier design. However the change to avahi and the port forwarding rule is still leaves a certain distaste in my mind. Therefore I would like to improve this design too - it's a good step but need to refine the design a lot more. I have an idea of a reasonable middle ground I'll try and put forth in my next post. For now, I'm definitely open to hearing a fresh perspective :)