In the blog titled Power of Cloud Application Centric Infrastructure (Cloud ACI) in Service Chaining, we talked about how cloud ACI provides an elegant solution for lifecycle management of native load balancers in the public cloud. We also looked at a simple use case of a Firewall insertion before traffic hits the application load balancer. In this blog, we will look at more complex use-cases that we can solve using a comprehensive service chaining framework with Cisco ACI.
Protect your workloads with seamless Firewall insertion
With security a top-of-mind big concern in the public cloud, customers want traffic inspection not just for traffic incoming from the internet into the customer applications in the public cloud, but also for the traffic within the public cloud namely, across VPC’s (AWS)/ VNETs (Microsoft Azure). Let us take an example of a customer running each application in a different Virtual Network in Azure. Traffic from the web application in the Web VNET needs to be inspected before it is sent to the backend application running in the App tier VNET. This typically means a firewall or Intrusion Detection System (IDS) or an Intrusion prevention system (IPS) device insertion in the path between the two applications. Traffic sent by the web application needs to be redirected to IDS/IPS and sent to the backend application only if the inspection device deems it ok.
Cloud ACI seamlessly automates not just the networking but also the security group configuration all the way from the Web tier servers to the App tier servers and everything in between based on the service chain and the contract between the two applications. The inspection devices (IPS/IDS) are typically behind a network load balancer to cater for high availability. The topology would look like below:
In the diagram above, the backend application is fronted by an application load balancer, called an application gateway (AGW) in Azure. Remember that the web servers are talking to the Virtual IP (VIP) of the backend application hosted by the AGW and have no idea about the firewall. So, how do we insert the firewall in the path between the two applications?
Realize the full potential of Cloud ACI
Cloud ACI provides a truly innovative way for customers to achieve this by providing a very flexible model of configuring a service graph. Create a service graph by adding the network load balancer (NLB), the firewall and the application load balancer specifying the service chain. While adding the NLB, the service graph lets you specify a “redirect” option on the consumer and provider connectors. By selecting this option, traffic from the Web VNET destined to the application tier will be redirected to the NLB. Similarly, the return flow from the APP tier to the Web will also flow via the NLB.
Cloud ACI achieves this by automatically programming a User-defined route (UDR) in the Web VNET route table. The route points to the NLB VIP as the next-hop for traffic destined to the AGW VIP, as shown in the below diagram.
The firewalls are typically deployed in a 1-arm mode for this use case. UDR installed in the Web VNET will redirect traffic destined to the application VIP 12.1.0.10 via the NLB. The solution uses the
high availability port configuration provided by the Azure NLB. This lets the NLB pass all traffic received to the backend irrespective of port/protocol of the traffic. Hence, NLB sends all traffic it receives from the Web servers to the firewall. The firewall after inspection, sends it to the actual destination of 12.1.0.10. Notice that, in this flow the source and destination IP of the packet does not change. The source remains the web server IP and destination the AGW IP. There is no network address translation happening and hence debugging flows just got a lot easier! Cloud ACI also creates and programs the Network Security Group at every hop of this flow.
This enables full automation of your cloud network and security policies. And, this works even if the Web and App VNETs are in different regions. No more manual configuration of these complex service chains in your network!
Source: cisco.com
Posts
0 comments:
Post a Comment