What is Group Based Policy (GBP)?
The main aim of group based policy (GBP) is to capture the applications requirement without introducing the complexity of how underlying infrastructure works. Its a new framework, which offers a new set of API extensions to manage OpenStack infrastructure through declarative policy abstraction (A model, which says what to do, not how to do).
Some of the challenges in neutron networking:
Neutron was designed as a network abstraction layer for OpenStack. But this approach is having some drawbacks if we see it from end user or application point of view. For instance the properties of virtual machine or application are defined in a number of places. Its security policies are part of security group construct, neutron network is used to describe its connectivity requirements. This is not intent based. Below picture gives a clear view.
Lets take an example of creating an instance (For application deployment) in OpenStack and provide network connectivity. Below are the steps need to be followed.
1. Create a network.
2. Create a subnet for the network
3. Create a router (optional) for external connectivity
4. Attach the router to the subnet.
5. Boot an instance providing network ID.
6. Add security groups (policy)
Above procedure involves deep networking knowledge and need to think of different layer of OSI stack for application deployment
Group-Based Policy solves the challenges involved in above approach.
Group-Based Policy aims to address these issues by offering a simple, abstract API designed to
capture user intent. It is based on the following key concepts.
1. Group: Collection of network endpoints and everything in the group must be treated as same way.
2. Reusable Policy rule sets: This offers a simple way, how machines can communicate in non-networking terms.
3. Policy Layering: This concept allows policies to be layered, based on different roles in an organization and to specify the appropriate policy to an application.
4. Network services: Network service chaining is a mechanism for connecting multiple Layer 4 through Layer 7 services such as load balancers and firewalls. This allows application developers to specify requirements as components between a combination of groups rather than through switching or routing configuration.
Below picture describes, how group captures properties of VMs. Here rule sets provide abstractions and it is intent based.
Group-Based Policy Architecture:
It is designed to fit seamlessly in OpenStack architecture. It provides a horizon GUI, CLIs and heat extensions for interacting with its API. It also supports a number of back end drivers. One is neutron driver, which will convert group based policy directly into the neutron API, so that it can be used with any existing neutron plugin and ML2 diver. It also supports opendaylight(ODL) driver. It is designed in such a way that it can support vendor drivers and in future it will expand to support nova, cinder and other OpenStack component drivers.
Group-Based Policy Model:
Action: Defines what action has to be taken on the traffic
Classifier: Defines or classifies the traffic
Policy Rule: Combination of classifier and actions (to be performed on the traffic)
Policy rule set: Set of policy rules
Policy Group: Contains group of virtual machines and associated rule sets and everything in a group act as same
A 3 tier application deployment using GBP.
In above application deployment the traffic(http traffic) comes from web-group (web layer) is being redirected to service chain (firewall and load balancer). And the traffics from web-group to DB-group (database layer) are not allowed.
Action: Defines what action has to be taken on the traffic
Classifier: Defines or classifies the traffic
Policy Rule: Combination of classifier and actions (to be performed on the traffic)
Policy rule set: Set of policy rules
Policy Group: Contains group of virtual machines and associated rule sets and everything in a group act as same
A 3 tier application deployment using GBP.
In above application deployment the traffic(http traffic) comes from web-group (web layer) is being redirected to service chain (firewall and load balancer). And the traffics from web-group to DB-group (database layer) are not allowed.
CLIs: Create two groups and allow icmp traffic in between them.
Creating actin, classifier, policy rule, policy rule set
gbp policy-action-create [ACTION_NAME] --action-type allow
gbp policy-classifier-create [CLASSIFIER_NAME] --protocol icmp --direction bi
gbp policy-rule-create [RULE_NMAE] --classifier icmp-traffic --actions [ACTION_NAME]
gbp policy-rule-set-create [RULE_SET_NAME] --policy-rules [RULE_NMAE]
gbp group-create [GROUP_NAME1]
gbp policy-target-create [POLICY_TARGET_NAME1] --policy-target-group [GROUP_NAME1] - This gives PORT_ID
nova boot --flavor [FLAVOR_NAME] --image [IMAGE_NAME] --nic port-id=[PORT_ID] [POLICY_TARGET_NAME1]
gbp group-create [GROUP_NAME2]
gbp policy-target-create [POLICY_TARGET_NAME2] --policy-target-group [GROUP_NAME2] - This gives PORT_ID
nova boot --flavor [FLAVOR_NAME] --image [IMAGE_NAME] --nic port-id=[PORT_ID] [POLICY_TARGET_NAME2]
gbp group-update [GROUP_NAME1] --provided-policy-rule-sets "icmp-policy-rule-set=true“
gbp group-update [GROUP_NAME2] --provided-policy-rule-sets "icmp-policy-rule-set=true"
References:
https://www.youtube.com/watch?v=a3Ur1IDyALA
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-733126.html
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst
Thanks
Titu
