Showing posts with label Application Centric Infrastructure. Show all posts
Showing posts with label Application Centric Infrastructure. Show all posts

Sunday, March 15, 2015

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 3rd 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.

Thursday, November 20, 2014

OpenStack Series: Part 20 - Group-based Policy for Neutron

Group-based Policy is a new feature in OpenStack and is still in its infant state.  There is a page on this subject in the OpenStack wiki but not much information on what this feature is about. 

For 4 years I have developed and enhanced a feature on the Alcatel-Lucent Enterprise switch for a policy based network access control for network traffic.  I have with 3 other engineers submitted a patent in this area waiting for approval.  This is why I am particular interested to look into this Group-base Policy that is in OpenStack.  Actually, this also made it way into the SDN Controller OpenDaylight project.

This feature is supported by quite a few IT equipment vendors such as Cisco, Alcatel-Lucent (unfortunately I am not with this division such that I can work on this interesting project), Big Switch Network, Juniper, IBM, Red Hat and even Intel.

The main goal for Group-based policy is to provide support and abstraction for the application that is running on the OpenStack Infrastructure.

The whole idea is to provide an abstraction layer for the application so that it does not need to know the detail of the how the infrastructure that it is running on.   It is to use a declarative language to capture the intent of the application.  At this time the Group-based Policy is mainly for Neutron but it can also be developed to be applied to compute and storage.

Note: Declarative is an important concept. It is to defined the desired end state of a server or an infrastructure.  The popular Configuration Management Tool Puppet is a declarative language.  I have talked about OpenStack Congress and it is also a declarative model.

Currently the Neutron API is powerful in providing an abstraction to provide a logical network.  However, there is one drawback - it is very network-centric and user has to be very knowledgeable in networking.  The API may be a set of powerful API for network engineer but it may be too much for an application developer or operator to handle.

According to the OpenStack Documentation, Group-base Policy is to provide a intent-driven declarative policy model that presents simplified application-oriented interfaces to the user.

Application-oriented - Does this sound familiar?  For me I immediately think of the Cisco version of SDN (Software Defined Network) - Application Centric Infrastructure (ACI).  Of course, the APIC driver is part of Neutron's ML2 mechanism module.  ACI by itself is a big topic to be discussed.  I will most likely look into this in the near future as part of my quest to the cloud related technology.  When I look into this subject of Group-based Policy, I find the most informative information comes from Cisco's blog and/or white paper.  I think Cisco contribute to this Group-based policy feature and is driving the advancement of this feature as well.

While I think even Cisco is driving the advancement and acceptance of Group-based Policy, it has it value and is not a feature that is pushed by a vendor for their sole benefits in this case Cisco and ACI.

Group-based Policy Architecture


image source: http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-733126.doc/_jcr_content/renditions/white-paper-c11-733126_0.jpg
I found that this Cisco white paper is a very good description of the Group-base Policy's architecture.  There are 4 main concepts that are essential to Group-based Policy:
  • Groups: network endpoints are put together in a group and the properties of the endpoints are treated as a whole.
  • Policy Rule Set: This describe how the groups are connected together
  • Policy Layering: Policy can be layered on top of each  other forming a new/combined policy.
  • Network Service Chaining: This is an important concept in NFV (Network Function Virtualization). Group-base Policy allows applications to define their requirements on how the packet flows.
According to the Cisco white paper, this Group-base policy has the following advantages:

  • Automation and security are much easier to implement through Group-Based Policy.
  • Offers a naturally flexible and extensible framework for capturing the requirements of a virtual machine in a single location.
  • Makes consistency easier to achieve because only one step - becoming a member of the group - is required to inherit multiple policies 
  • Easy for application developers to use and offers them a simple way to describe application requirements 
  • Offers a means for allowing operator and user requirements to coexist cleanly 

Group-based Policy and OpenStack


image source: http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-733126.doc/_jcr_content/renditions/white-paper-c11-733126_2.jpg

Also, according to the same Cisco white paper, Group-based policy is supposed to fit into OpenStack in a "non-disruptive" layer.  I take it as not or minimum changes is need in OpenStack.  When we look at the diagram above Group Policy is the orange layer and conceptually this is how it fits into the OpenStack.  We can see the Horizon and Heat module along with the OpenStack CLI sitting on top for configuration (manual or via a Heat Template).  The next layer is the application in which all our focus are in to making the deployment of application as easy as possible without have to "worry" about the supporting infrastructure.  Below the Group Policy layer are the other various OpenStack projects. At this time it is mainly focused on Networking.

Group-based Policy and OpenStack Congress
On the SDN front, we see that VMware and Cisco are going the opposite direction.  OpenStack Congress is heavily driven by VMware while Group-based Policy is heavily driven by Cisco.  Will the same thing happen here where the 2 technologies are competing with each other?

It seems that Congress covers governance and compliance while Group-based policy is to capture the application's intent and to provide an abstraction layer.  These 2 things compliment each other and is providing different services to the OpenStack users.


Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a Web Based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack

OpenStack Series Part 17: Congress - Policy Service  
OpenStack Series Part 18: Network Function Virtualization in OpenStack 
OpenStack Series Part 19: Storage policies for object storage

Reference:
"GroupBasedPolicy." - OpenStack. N.p., n.d. Web. 09 Nov. 2014.