Who do you trust? - nobody

It is not about me. I do have faith in the human race and there are people that I trust.

It is about a new security model proposed by Forrester Research in 2010.   

Traditional Network Security

The problem with the traditional network security model is that it assumes anything outside the network is untrusted while everything inside the network is trusted.  Heavy emphasis is put at the edge for network access control.  Once a user is in the network, there is not much control. 

There is the Role Based Network Control (RBAC) in which based on the credential of a user and sometimes based on where and when the user is trying to access the network, a role is assigned to the user after the user successfully authenticates with proper credential. It is more useful when RBAC is implemented at the application level. To implement RBAC at the network level, security control is still limited.

With the proliferation of server virtualization, virtual machine can move from one host to another host.  This makes the application of security control more difficult - where is the perimeter?

Before we go on we need to spell out 2 definitions: 

• East-West traffic: it is the traffic between servers within a datacenter
• North-South traffic: it is the traffic between client and server

Traditional security model mostly tailor to north-south traffic and not much is done for east-west traffic.

Zero Trust Security Model
The "Zero Trust" security model is proposed by John Kindervag, a senior research analyst at Forrester Research.  His report can be found here (you have to paid to read the full report).  Well, we can also listen to John Kindervag talk about this "Zero Trust" model here in YouTube.  Actually the name of this security model captured the essence - "Trust no one".  From the YouTube video, John Kindervag mentioned 3 concepts for "Zero Trust" security model:

1. All resources are accessed in a secure manner regardless of location
2. Access control is on a "need-to-know" basis and is strictly enforced
3. Inspect and log all traffic

To implement this on the traditional 3 tier network (access/aggregate/core) is not easy.

Today let's take a look at VMware and Cisco products that utilizes this "Zero Trust" security model.  This security model also protects east-west traffic between servers.

VMware
VMware implemented Zero Trust security model in its NSX product.

VMware NSX is well known as a Software Defined Network (SDN) feature.  I have in another post stating that NSX is also a security product and according to Chris King, vice president of product marketing for VMware's Networking and Security Business Unit, a lot of customers show interest in NSX because of its inherited security feature because of it design. 

NSX is a network virtualization platform and is able to automate, provision and managed network connectivity in a data center.  With NSX there are 3 levels of security that can be accomplished:

1. Isolation
2. Segmentation
3. Advance Segmentation with 3^rd party security partners

Isolation
In traditional network, Access Control List (ACL) is used for isolation.  With a virtualized network, the virtual network is by default isolated from the physical network.  Each virtualized network are also being isolated with one another.  This follows the zero trust principle a the virtualized network level.

Segmentation
In NSX, there is a concept of micro-segmentation.  In the traditional network segmentation is done through VLANs.  With a virtualized network, segmentation is not limited to a VLAN but can be fine tuned to smaller group of virtualized resource or even to an individual virtual machine.  In fact, as this will be explain again later in this post is that micro-segmentation is how VMware achieved the zero trust security principle.

Advanced Segmentation with 3rd party security partner
With service chaining, NSX in a virtualized network can direct the data traffic to 3rd party security appliances for deeper packet inspection and ACL parsing. 

The main idea for NSX to accomplish the zero trust security model is to have a distributed firewall (one on each ESXi host) and that traffic is inspected before being sent out to the traffic. Even if 2 VMs are connected to the same vSwitch, the distributed firewall is going to inspect the data traffic before sending to the destination VM. Without the distributed firewall, the 2 virtual machines connected to the same vSwitch are able to pass traffic between each other.

This diagram explain the concept that with the distributed firewall implemented at the hypervisor level, we can accomplished the zero trust security model where all traffic is being inspected and filtered according to the security policy defined:

image source: http://wahlnetwork.com/wn/wp-content/uploads/2014/08/nsx-firewall-yes.jpg

Cisco
Cisco's Application Centric Infrastructure (ACI) supports the concept of this Zero Trust security model.

As the name of this feature suggests it is all about - Application.

Traditional network security is network based, ACI decouples the security policy and segmentation from the network and defined "application friendly" policy model.  Security policy model in ACI is not only MAC address and IP address or its port number.  In ACI the security policy is defined by:

1. Endpoint Groups (EPG)
2. Policy Contract
3. Application Network Profile

image source: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW0Iql3smClfr6IFq9HOoNyFuW3HSslh5GjTGqyhkuZif90vZW8xjGCEMAMKErB3L6FfM8mnWrameSER9ChsJVQ2LKTLEZLR6JfR9Ko_PMuzftb21dZxObYRIfLh9WVjf4lD7052xXweE/s1600/cisco_aci_PolicyModelForSecurity.jpg

Endpoint Group

Devices with a common policy is put together as a group. It can be based on application friendly attributes such as OS, patch level, application type, application component or function.  Endpoint Group once created can be used to define security zones, trust boundaries or risk profile.  In ACI the default is no trust.

Policy Contract
The contract defines how data traffic is delivered between Endpoint Groups (EPG). This is is how the security rules are applied to devices regardless of where they are. In a virtualized environment, virtual machine migration is common. This contract defines filters and any associated action.  This is similar to our traditional firewall rules which based on the 5 tuples.  Policy contract enforcement for Endpoint Groups can be unidirectional or bidirectional.

Application Network Profile
In the diagram above this is stated as Service Chains.  Service chaining is a concept in which it defines the flow of the data traffic from one network service to another service.  Service chaining is a hot and important topic for Network Function Virtualization (NFV).

Trust and no trust
I believe the networking industry is catching up with the server and storage virtualization technology.  In a network we should trust no one but in our daily life we should have a certain trust level to other people that we come into contact with.  Everyday we are creating and updating out "Human Centric Profile" as to who and how much we can trust the people we know.

Reference:"Cisco ACI Security: A New Approach to Secure the Next-Generation Data Center." Cisco. N.p., n.d. Web. 13 Mar. 2015.
Egy, and White. Data Center Micro-Segmentation (n.d.): n. pag. Web.

Networking options for Docker

Docker is gaining popularity both in the new and in actual deployment.  Last time I talked about VMware is also embracing Docker technology.

Lets take a look at the different networking options for Docker.

Native Docker Networking

• On startup Docker creates a Ethernet Bridge docker0 on the Linux Kernel
• docker0 creates a virtual subnet on the Docker host
• Docker creates a pair of virtual Ethernet interface on each container
• One of the Ethernet interface is the eth0 in the container
• Another Ethernet interface will have a unique name in the form of veth* (e.g.vethABI3IC) and is bind to docker0
• User can customize docker0
• Advanced Docker networking can be found here

image source: http://www.infrabricks.de/assets/images/docker_network_basics1.png

Flannel

• reference articles An etcd backed overlay network for container, article1 and article2
• Used to be called Rudder
• An etcd backed overlay network for container
• flannel uses etcd for storage of both configuration data and subnet assignments.
• Upon startup, a flannel daemon will retrieve the configuration and a list of subnet already in use
• Select an available subnet (a randomly picked one) and attempt to register it by creating a key in etcd
• Works under Kubernetes
• Resolve the problem of native Docker networking where network address was hidden from the network outside of the Docker host machine
• It can work on any exiting network without changes to that network.

 

image source: https://github.com/coreos/flannel/blob/master/packet-01

Weave

• reference article
• An overlay networking system for Docker container
• Open source back by a commercial company Zettio
• The system consists of two components:
• Weaver - a virtual network switch and router implemented in Go that runs within a Docker container on each networked host.
• Weave - a script that wraps the Docker command line in order to start Weaver, connect containers to the Weave virtual network, and assign IP addresses to them.
• Zettio founder Alexis Richardson said "Weave makes the network fit the application, not the other way round"
• Can be think of as "a giant Ethernet switch to which all the containers are connected"
• Weave network can be encrypted
• Simplies the process of connecting containers together instead of using Open vSwitch

image source: http://www.infoq.com/resource/news/2014/09/zettio_releases_weave/en/resources/1Weave.png

Pipework

• reference article.
• Docker creates a special Linux bridge called docker0 on startup. 
• All containers are automatically connected to this bridge and the IP subnet for all containers is randomly set by Docker. 
• Currently, it is not possible to directly influence the particular IP address of a Docker container.  
• pipework is a shell script which user can use to add another interface to a container with a specified IP address.

SDN
SDN is an hot topic and Docker is another hot topic and what is going to happen when we put SDN and Docker together?

Recently a new startup SocketPlane has an idea of bringing Open vSwitch to the Docket host.  I read an article from SDN Central about SocketPlane:

• To have a container that is going to be able to manage the data path
• Also able to manage either overlays or underlays
• Will focus on network management and network services instead of the network system
• Will also address problems with DevOps with various Configuration Management Tools

When we go to SocketPlane's website you will see "Native to Docker", "Familiar to NetOps" and "Application Friendly".  I think this 3 phases summarize the product direction that this company is heading.  One thing to note is that the founders of this startup are all veterans of the OpenDayLight projects along with former executive from OpsCode/Chef.

I have another post on OpenDayLight previously, please take a look if you are interested. :)

Bring SDN to Docker can open up using a container for NFV or in this case NFD (Network Function Dockerization) <- a new name that I come up with based on the word "Dockerize"

Reference:
"CoreOS." CoreOS Blog ATOM. N.p., n.d. Web. 26 Oct. 2014.
"Coreos/flannel." GitHub. N.p., n.d. Web. 26 Oct. 2014.
"Zettio Releases Weave for Docker Networking." InfoQ. N.p., n.d. Web. 26 Oct. 2014.
"Docker Networking Made Simple or 3 Ways to Connect LXC Containers - Codecentric Blog." Codecentric Blog. N.p., n.d. Web. 26 Oct. 2014.
"OpenDaylight Coders Open Shop on a Docker Startup." SDNCentral. N.p., n.d. Web. 26 Oct. 2014.
"Docker Networking Made Simple or 3 Ways to Connect LXC Containers - Codecentric Blog." Codecentric Blog. N.p., n.d. Web. 26 Oct. 2014.