Networking

Private Virtual Network Configurations

This section offers a number of different private virtual network configurations that could be used in conjunction with an Immutable Service Containers implementation.  Each of these models offers distinct benefits and risks, and so no one approach is superior to the others.  As with any deployment, it is important to select a configuration that is optimized for the requirements at hand.

For each of the configuration models described below, a brief example highlighting the differences will be offered.  Each example will be based upon a deployment of a web stack that includes Apache/PHP, memcached, and MySQL.  That said, there is nothing in these configuration models that tie them to specific software applications.

Single Instance Private Virtual Network

In this model, the system is configured to receive traffic on a single public IP address that is mapped to the global zone.  All external communications with the non-global zone running on this system must pass through the global zone.  In terms of the mechanics, network address translation is configured in "hide" mode allowing the non-global zone to initiate IP communications.  Further, network address translation is configured in redirect mode allowing incoming requests to be selectively forwarded to the non-global zone based upon the IP address and port where the request was received.  Stateful packet filtering is implemented control and monitor which services are exposed to the outside world and to further restrict the non-global zone from directly communicating with the global zone.  Architecturally, this model is represented by the following diagram:

Typically, secure administrative protocols (e.g., Secure Shell) will be permitted to directly access the global zone.  By default, no services are exposed by the non-global zone.  When applications are installed into the non-global zone, this restriction can be adjusted to expose services on an as-needed basis.  Both the global zone and non-global zone by default can freely initiate outbound network communications.

Example: Since this configuration only has a single non-global zone, all of the web stack services (Apache, memcached, and MySQL) will need to be installed into this single zone.  The services themselves can be installed with unique credentials and least privilege in order to provide a measure of isolation, but ultimately, they are running in the same operating context.  This may be sufficient for some environments, but others may want stronger compartmentalization of services.

Multiple Instance, Shared Private Virtual Network

This model builds upon the previous one adding support for more than one non-global zone on the system.  This configuration uses a shared private virtual network for the non-global zones to communicate externally and with each other.  Just as in the previous configuration, network address translation and stateful packet filtering are configured allowing each non-global zone to freely communicate with external systems while at the same time restricting which services are exposed in which non-global zone.  In this configuration, non-global zones can communicate freely with each other (outside of the reach of the global zone's enforcement point).  If additional network restrictions are needed between non-global zones, application specific techniques or tools such as TCP Wrappers would be needed.

Example: In this configuration, each of the web stack services (Apache, memcached, and MySQL) can be installed into their own non-global zone.  In this type of configuration, they will each be run in their own security hardened operating context (and still will leverage unique credentials and least privilege).  This model offers a stronger form of isolation and allows each non-global zone to have an installation profile and hardening configuration that is tuned for the application being run.  For example, Apache may need software that is not required for MySQL.  In the MySQL non-global zone, that software would not need to be installed.  Note that in this configuration model, each non-global zone can freely attempt to communicate with all of the other non-global zones.  Typically, each non-global zone will expose only its required services, but this may still be too flexible a policy for some organizations as it could allow (for example) the memcached non-global zone to initiative communications with the Apache non-global zone (something that under normal conditions should not happen).  Again, while additional network filtering techniques can help to solve this problem, some may want strong forms of isolation such as in the models covered below.

Multiple Instance, Isolated Private Virtual Network

In this model, the notion of a shared private virtual network is replaced with one that offers (potentially multiple) isolated private virtual networks connecting specific non-global zones to each other (and the global zone).  This configuration approach ensures that communication paths between non-global zones only exist if they are needed.  This certainly helps in terms of isolation, but it does make the resulting configuration a bit more complex.  This model can be used to ensure that communication paths do not exist between the outside world and a given non-global zone (such as in the two, right-most non-global zones in the diagram above).  In a virtual three tier architectural model, for example, this type of configuration can be used to ensure that the "web" tier is not able to directly communicate with the "database" tier.

Example:  Just as in the above configuration, each of the web stack services is installed into a unique non-global zone.  Unlike the prior configuration however, this model ensures that the memcached non-global zone is not able to directly communicate with the database non-global zone.  This is just a respresentative configuration, but the goal is to illustrate the type of isolation possible using this model.  This approach does share the challenge that each of the isolated private virtual network links allows pairs of non-global zones to communicate freely with each other (subject to application-level or non-global zone specific filtering policies).  A benefit of this model, however, is that only the Apache non-global zone is connected to the external world (through the global zone).  This means that the memcached and MySQL non-global zones are no longer reachable from external network sources.  This kind of isolation can be very useful, but it can also pose challenges for installing and updating software from network repositories.

Multiple Instance, Mediated Private Virtual Network

In this next model, the notion of isolated networks is made virtual through the use of the global zone which acts as a mediator for all network communications flowing between non-global zones.  Each non-global zones is assigned its own virtual network in this model and it shares that network only with the global zone.  This allows the global zone to act as a mediator and monitor of network traffic flowing between each non-global zone.  The global zone enforces policy that specifically determines which internal (between non-global zones) and external communications are permissible.  This model has the benefit of providing greater control and monitoring of communications between non-global zones at the expense of a slight increase in configuration complexity (each non-global zone requiring its own private virtual network).

Example: This configuration provides the highest degree of control over network communications.  In all of the model discussed above, external communications with the global zone and its non-global zones could be strictly controlled and monitored.  This model goes beyond each of the above scenarios however in that the communications between non-global zones can be equally mediated.  This would allow the system to ensure that Apache could only initiate communications with the memcached and MySQL non-global zones (using only their exposed network ports) and that communications could not be established in the other direction.  Each non-global zone does have a communication path to the global zone, and so in this model it is possible to allow each non-global zone (temporary) access to external network services for software installation and updates.  When this access is permitted and for what services, networks, etc. could be strictly controlled by the non-global zone.

Multiple Instance, Mediated Private Virtual Network with Unique Public IPs

This final model is similar to the Multiple Instance, Mediated Private Virtual Network approach with one important twist.  Each of the deployed non-global zones has an associated public network interface and IP address.  In all of the previous models, network communication was limited to a single public network interface and IP address.  Such a model is easy to deploy as it simply looks like a single node on the network (regardless of how many ISC Nodes are deployed within it).  This approach is limiting however as it is not possible in this model to configure non-global zones to all share the same TCP port.  For example, if each ISC Node was configured to be a web server (listening on TCP/80), only one of those ports could be publicly exposed.  In order to communicate with the other nodes, port address translation would be employed to map alternative ports as needed.  While this is effective, it is also non-intuitive.  As a result, this new model has been developed to overcome this specific problem.

Example: As noted previously, this model is essentially the same as the previous one with one important exception.  Rather than exposing network ports through the public network interface used by the ISC Dock (i.e., global zone), this configuration employs public network interfaces and IP addresses for each of its ISC Nodes (i.e., non-global zones).  This has the benefit of allowing each ISC Node to share services on the same network ports without the need for port address translation or other mappings.  In every other aspect, this configuration is the same as the Multiple Instance, Mediated Private Virtual Network model above.