Security Simplified: New Integration Between Cisco ACI and Palo Alto Networks Firewalls (T1272)

thanks everyone for joining us in my opinion this is a historic moment and here is why have you ever seen palo alto networks and cisco under one roof like co-presenting together on one stage and as i have not seen so far in my decade years of experience neither in Cisco lies not in ignite but he at ignite is the first time both Cisco my old friend and colleague Mauricio and I are Co presenting and the people who are making this happen is you guys the joint customers who are making this happen so thanks so much for that I think in the interest off the joint customers will break any business that comes on the way so with that let's get going before I start I would like to know who is in the audience so tell us a little bit more about where you are on your ACI journey how many of you have implemented is here in production all right about 30% of you how about Cisco Asya in the lab yet but not in production all right about 15 20 % third option I'm still evaluating Sdn solutions in the market all right maybe most of otherwise all right the remaining looks like you need a place to crash so welcome when you walk out of this door I want to make sure that you have a thorough understanding of these three things the first one you will know how cisco a CI and palo alto network service insertion works together you will know everything about our latest and greatest integration the the most advanced one that we have developed in the market yet and how customers benefited from the integration unfortunately we do not have a customer on stage yet because of some travel advisory they got from their company that about Salona it's a risky place right now to go so the travel was avoided but I have a customer slide and I'd be the one presenting the use case where they deployed our integration and how they benefited from it so with that let's kick it off and I would like to invite Maurizio on stage to talk about ACA fundamentals for those of you who are new to AC I have not deployed a CI in production yet so for some of you might be a repeat but it would be a good refresher well so yes I mean okay so allow me to explain to you what a CI is I mean for those of you who have it in production maybe it's a bit repetitive but at least everybody's on the same page with regards to a CIS technology so as the slide depicts a CI is a fabric made of multitude of switches we normally call these spines and then you could have one or two tears of lip switches so this is what you would put in place in your data center to connect servers and virtual machines to it as well as routing devices to connect to the outside and the entire fabric is managed through the controllers that here are depicted with this icon and that's where you would normally interface with the UI or with automation tools or with the rest api calls and so on so it's a an infrastructure that is designed for automation from day one there's been a lot of focus in the very beginning for that that's one key aspect of a CI so it's very easy to make changes that apply to you know very large infrastructure if you happen to have one but it's also an infrastructure it's easy to make you know self-service portals for you know people to instantiate their own network on the fly and so on the other key aspect of the ACI fabric is that it's designed with this policy model and the policy model is the definition of which security zones are in place and how they are supposed to talk through filters so in this simple example you have something that defines the outside Network then which filters or which kind of layer for like seven devices you want to have the traffic go through before the client requests get to the web servers and then here this is define how the web server security zone is allowed to talk to the app server second reason and so on so there is this model this policy model that is what you end up configuring on a you know regular basis and in provision and the Commission and so on now underneath the forwarding is based on a the exelon infrastructure so all the leaves are basically be excellent tunnel endpoints and they provide all the leaves here provide the default gateway to the server so the VMS and the same before gateway address is available anywhere in the fabric so you don't have to you know keep in mind or the VM is on this leaf what's the IP address here for the if ok it's the same wherever the VM moves so there's this concept of any COS gateway through VX LAN the forwarding allows you to have both layer 2 connectivity as well as they 3 connectivity so if two VMs need to communicate the layer 2 the transport is you know a be excellent via an ID which identifies the layer to the main if communication happens as a routed communication then TTL is decreased and so on and so forth but underneath the transport is always the excellent frames so this is showing traffic from one leaf to another one or traffic switch locally and in terms of going back to the policy model and going back to how workloads are allowed to communicate the definition is based on on this building block called an endpoint group or EPG for short and contracts and so you could think of contracts as a classic ACL with the key difference that instead of entering source IP destination IP the configuration is based on source and destination EPG and which filters are allowing the traffic or which firewall devices or role balancers are meant to be in in the path okay so so the classic contract would be let's say allow port 80 or 443 from external IP geez - EPG web but then you could also decide to just say you know I want to have for either for all the traffic or for a specific set of ports I want to have the traffic filter by a real firewall alright so Palo Alto for instance so this is how the policy model looks like now you have to also define which workloads end up into each one of these security zones so there's a key configuration that consists in defining the classification of the traffic so for traffic that arrives to a CI through routing devices from the outside the classification is based on IP network and mask so you would define you know this subnet belongs to this security zone and you could have multiple of them there's not just one external EPG you could have hundreds of them to categorize the traffic coming from the outside into multiple zones now for the workload directly connected to the ACI fabric or connected to the ACI fabric by a virtual switching and these kind of things you could do you can do more sophisticated classifications so the simplest option is to say traffic from this port and this villanies is the Curie's zone but you could also say traffic from this IP is the security zone and not this one or traffic from this MAC address is in the secure zone or you could go all the way to say this VM attribute like this VM name or some label you put onto VM belongs to this security zone or a different one okay so the classification can be based on many levels of granularity and it's also available for both physical servers as well as virtual servers and you can have endpoint groups with a mix of physical and virtual servers and they're all classified in the same EPG it's not a problem at all so based on that classification then you can have security rules as we said in the beginning so you can say which ports are allowed between the security zones but not only if workloads are connected to the same host or the same leaf but also if workloads need to communicate across different switches across different Leafs or even across different data centers since we also allow you to carry VX line across the planet okay and that information is the security zone information is part of the be excellent headers so there's a source the source class ID which defines the source EPG basically and the packet carries also information about which vrf it belongs to and also there are some additional bits that indicate whether the filtering has already occurred or has yet to occur because it could be that on the ingress switch there is enough information to know which security zone the vm belongs to but maybe there's not enough information to figure out where it's going to in terms of secure is own so if that's the case the packet can still be sent indicating that the source filtering has not been applied and then it's the work of the egress leave the inter switch to apply the filtering for that traffic ok so that's how the information the security information is carried across in on the data plane now the policy model is part of a bigger picture so not only you have the definition of endpoint groups and contracts and so on but all these building blocks all these configuration elements they are part of something called the tenant ACI a defines let's define configurations based on tenants so whenever you define some new security configuration for endpoints it's always part of a tenant so a CI is designed to be a multi tenant within the tenant there is the definition of vrf or more so it could have you know one or more brf's and within the BRF you define the layer two domains the bridge domains which could think of as the classic villains but there are villains based on the excellent en ids so there are bridge domains meaning routed constructs but they look and feel like the classic villain so it's a layer two domain it does leave two forwarding and these kind of things and then the security zones further carve the bridge domains into smaller subsets so here you have a PG web and app as a subset of bridge domain one and EPG database as a subset of the bridge domain two just as an example so you can have more than one security zone per layer two domain so this is a bit different than classic networks because in classic networks you would often define different VLANs to segment traffic that belongs to two different security zones in a CI to define two different surahs owns you don't create different bridge domains you can if you want but you're not obliged to you would define a bridge domain and then carve it up into multiple endpoint groups or into multiple security zones okay so let's talk about now the insertion of firewalls and more specifically insertion of Palo Alto into this picture ACI has multiple ways to define how you can insert a firewall or lived for layman device in the paths in general and some of them are probably very familiar to you because the look and feel like classic networking but then there is the one that we really like to draw your attention to which is called policy based redirect or service graph redirect so let me quickly give you an overview or what service graph with PBR is before we talk about all the various flavors of integration so we service graph redirect what you normally configure is just regular vrf and bridge domains and EP G's for the connectivity of the servers and whether you're gonna have a firewall or not in the picture you don't need to make anything different I mean you just configure bridge the main says you need to you just configure that your app says you need to you don't have to think about ok the default gateway maybe the firewall or oh I need to create two villains to pass traffic to the fire no you define the networking connectivity for your servers just like you would regardless of firewalls or live for devices now how then traffic goes through a firewall with this kind of design well we have this feature called service graphic PBR where you can say the traffic from this securities on to this secure zone instead of having to be routed in the classic way by looking at the routing table it should be redirected to these other bridge domains where only the firewall is connected ok so when a CI forwards the traffic it checks the source EPG destination EPG and then it can say oh then I shouldn't do any routing here I should just do redirection to the firewall the fire will then do whatever needs to do and forward traffic to where it needs to go ok so with this kind of design that we fir Gateway for the server's is not the firewall it's a CI ok so easily for Gateway the firewall doesn't have to be in the same bridge domain or in the same villain as the server it's it can be if you want to but it doesn't have to and yeah in other words you can insert the firewalling capability when you want without having to range near the way you divided the network into layer 2 domains or the way you define before gateways okay so that's one of the interesting points about using this model to insert the firewalls but now let's take a look at the barriers in deployment models because PBR is just one of them but I believe the other ones would be no news to you it's the classic way to insert firewalls in any network so you can use a design where the firewall is the default gateway so the firewall will be connected to an EPG on the same BD as the servers and the server's default gateway will be as you see here the firewall interface itself so this is you know how often people deploy firewalls before gateway for the server's and you can do the same in a CI another way to insert a firewall which is also popular is sometimes referred to as BRF sandwich benning you could define different brf's and then put the firewall between these via wraps and in this case the flow gateway for the servers will be a CI but then the configuration will be the classic routing configuration would have maybe static routes or dynamic routes between a CI and the firewall and then between the firewall and a CI again on a different vrf and so on so all the traffic in both cases would go through the firewall in both designs okay here they would just be a bridge domain configuration and here you would have to allocate different brf's and then we have this construct called layer 3 out which is just a wrapper for routing configurations so that's where you put your BGP or your static routes and you would need to one per BRF to pass traffic through the firewall so these are if you deploy a fire one in routing mode in layer 3 mode these are the classic way to add the firewall and then the last one which is you know dB what I would say the newer option and also maybe the most interesting one is the one we described in the beginning which is called policy based redirect so the default gateway for your servers will be a CI but you don't need to configure routing between the far wall and ACI the forwarding would be based on redirection and then on the far wall would have just a static route to a CI so traffic knows that to go to whatever needs to go we need to be sent back to a CI okay so traffic here flows through the firewall not because of dynamic routing not because of static routing but because of redirection and from the firewall back to AC I would just be a a default route typically right so this is based on a building block design configuration that in a CI that is called service graph you need to use this construct to make the traffic go through through the firewall now for insertion of leave for devices they've released a new license in layer 2 mode or layer 1 mode you can also define them in a CI you can configure them in a CI in a classic way so one way to do so is to define it to bridge domains so in a classic network you will find two villains in a CI you defined to bridge the mains but it boils down to the same the default gateway for your servers would be a CI but on the opposite side of of the firewall so will be the a CI interface on this layer to domain and this layer to domain will just be purely to be no browsing interface here so all traffic will flow through the firewall but we also have the option to do redirection like PBR also for the layer 2 mode which is something quite new so in this case you would not need to create two bridge domains to pass the traffic through the firewall so your servers will be on their bridge domain the default gateway will be a CI and yet a CI is able to redirect the traffic through a layer 2 device so there will be still two bridge domains for the layer 2 device because array 2 device expects to bridge domains but they don't need to be the same ones as where the servers are so what's nice about this is a game that you could have a network defined designed for server connectivity and you add later on your redirect redirect relate to device to relate to firewall without having to split bridge the main where the server is so that's one of the reasons why you would want to do this and then there are the benefits of policy-based routing which will describe additional benefits of policy-based routing which will describe in a few slides let me zoom in on the layer 1 layer 2 PBR layer only to service graph redirection it's another way to look at the traffic flow so imagine you have two servers in the same layer two domain and they can be able to simulate to the main and be part of two different security zones because you can use endpoint groups so you have PPG client one in PG server one which are a carving of this bridge domain so you have these two security zones and then you put service graph to say even though they are in the same leaf of domain they need to go through the firewall and the firewall is operating like a two mode so for for you to do that you will need to define these other two bridge domains which are not for not for the endpoints not for the server's connectivity they are just for the firewall connectivity and then the service graph configuration would say the traffic from this EPG to TCP G has to go through these paths okay so here the devices are a two mode but as you notice we're not breaching villains where the servers are so that's that's how the topology looks like and AC I will rewrite the Mac of the traffic here to be the destination marking can be like the opposite bridge domain so the traffic is obliged to flow through the layer 2 device out there so it's a different way to insert layer 2 devices in the path and one of the advantages is that if you have later filing in the classic networks you're basically bridging VLANs and as you know when you bridge villains there's also chance to introduce potential loop with a CI you're doing the same work of bridging violence but in dedicated bridge domains which arguably you could also introduce a loop there but the difference is that you're not gonna bring loop that consumes bandwidth on this bridge domain but will be separate bridge domains so the chances to affect more servers are limited and constrained so that's one interest of doing this this kind of following it's kind of implementation but let's then focus on what are then the reasons to use for instance service graph redirect a service class PBR versus classic deployments so we mentioned some of them but let me highlight a few additional reasons well first you can say in a CI that not all traffic has to go through the firewall you could say only specific ports right so you could say I don't know ICMP could be direct between IP jeez and then poor eighty could have to go through the file that's one reason the other one is you could say that traffic from say any pinpoint group and the outside must go through 501 and then these are the repeat g2 the outside has to go through five or two or you could also say I want traffic from you know for port 80 to go through one five one for port 8080 through another firewall and all the CPGs could be the same bridge domain so that's the difference with classic networks you don't care anymore about later domain you care about the security zone DPG one more reason this is more for the load balancers if you don't want to do source not on the load balancer you can use service grab redirect to return traffic through the load balancer on the way back from these servers to the but one of the key I mean as we said in the beginning one of the key interest of doing service graph redirect is the flexibility that this gives you at the design level meaning even if you want to deploy securing stages you don't need to plan the one for the fact that you need to add the firewall later on you can design your later network or relay free network from the beginning just like you would with the outer firewall and then insert the file later on for all the ports or for specific ports and you know you can do that at a later stage if you want so this gives you this extra flexibility and then ACI also gives you some extra flexibility with service graph Friedrich because you could have servers of the same subnet filtered through the firewalls you don't have to again split the bridge domain in two but you could even go as far as saying that servers within the same security zone they have to go to the firewall so you can also do service graphi direction inside of the same security zone like what you see on the right of this slide so that's another interesting point you can also this also gives you the flexibility to attach firewalls in the topology wherever you like they can be they don't have to be on the same leaf of the servers they can be on any leaf of the fabric they could even be in a different data center if you want because a CI can also give you that flexibility and the interfaces of the firewall can be on you can put them on a dedicated bridge domain so that multiple plates domains will all use the same interface so you don't have to configure one per bridge domain on the on the firewall but you could also have the interface of the firewall on the same bridge domain as the servers if you so desire so it you have said that that flexibility and it doesn't have to be that the firewall is the default gateway okay so you could have an interface of the firewall on the same layer to the main of the servers and yet use the redirection to push traffic to the firewall so you can have both now another extra advantage of of service graph redirect is that if your firewall pair is not enough and if you want to scale the capacity of the fouling infrastructure acia allows you to add more than one firewall and a CI will take care of hashing traffic through multiple firewalls and do it in a symmetric way so that your flows are not are not going to you know in a symmetric way to the firewalls so you can do redirection and combine it with the ability to hash you know hundreds of eye rules if you so desire with symmetric redirection so instead of one firewall you can have like this example three of them and then HDI will take care of to do load distribution across across them and what if one of these firewalls goes down okay so a CI does monitoring so for the layer three mode the monitoring can be based on ICMP TCP etc for the layer two mode there's also layer two pink which checks whether the firewall is there and then if the firewall is not reachable a CI can take it out of the pool and it will rehash the flows that we're going through that firewall to - one of the other links okay so that only the flows of the firewall that went down are affected by the fader not it's not recalculating the hash for the entire pool is just reallocating the ash for that specific firewall that went down and then you can have policies that decide okay if so many of the firewalls went down then take firewalls completely out of the equation and you can decide whether you want to fail open or fair closed up to you to the side and then you can say that the entire service can be brought back online once you have more than a certain percent of available notes and then you know once you go like - more than 80% of the notes are available then you can say okay now we do PBR again and you know traffic is to go to the firewall so you also have all these levels of control to define when the service graph redirect should be operational or not and then if it's not you can decide whether you want to have a permit or a deny for the traffic another benefit another problem with that these technology solves is the security across multiple data centers because in a classic design if you're multiple data centers and traffic may be entering from one from these firewalls and then going to the other one there's always the risk that the return traffic is going through the local firewalls and this will not work right because traffic flows will not be known to the firewalls here parathion and traffic will be dropped a CI allows you to solve that problem by relying again on this technology on service graph redirect so that traffic that is destined to this endpoint may be entering through this path and then the resurrection occurs on this leaf so the traffic goes to the local firewall and then if if the traffic happens to be going to the opposite data center the direction is applied here so the traffic is filtered in both direction through this firewall so this ensures symmetricity also when you have dispersed data centers by relying on on the service graph redirect feature you can also control traffic and make sure it enters directly where you want to so there's no need to do this path but if it happens to be doing this but this is solving the problem so these are the these are the scenarios that service graph redirect helps helps with now needless to say we're also investing a lot and developing a lot for the integration with cloud so you know you also find the service graph feature available when you you know when you connect your workloads also for instance but they're just for you to know it's not we're not gonna go any deeper on this particular aspect of the design and now I let Simon talk about the specific integration with with Palo Alto thank you very soon all right so Quick Poll again how many of you are doing east-west firewalling like how many of you are inspecting the traffic in east-west direction alright about four or five hands about ten percent of you all right good to know and how many of you are using virtual firewall to do that anyone right one out of four like very person let's hope you are using either visas or leveraging the same firewalls yeah okay all right good you know thank you so these are the three key benefits of our integration with Cisco ACI the first one is the deployment flexibility second one is you'll be able to secure multi tenant data centers and the third one is we'll be able to secure dynamic workloads and I'll double click into each of them when I talk about deployment flexibility is it's all about form factor level freedom and also operational mode level freedom our integration with Cisco ACI works equally well with both Hardware firewalls and virtual far was literally zero difference so you have the freedom to pick either hardware or virtual but the integration would work in both you can also deploy our firewall in layer 3 layer 2 layer 1 mode and pack it can be paired with layer 1 layer 2 layer 3 PB a-- right so both the modes operationally and form factor wise it would work when it comes to securing multi-tenant data centers understand that ACI has a very nice multi tenant capability in its architecture multi-tenancy is inbuilt into it from day one so you can use the shared firewall if you are using hardware firewall you can have the hardware firewalled placed in a tenant called tenant common and then all other services all other your application tenants can is the same very same firewall and you can redirect the traffic through that shared common Farwell you can use if you are using virtual for was then you can use zones to achieve the multi-tenancy if you are using hardware firewalls you have the option to use visas other option that we are seeing among our customer base that they are using his for north-south inspection primarily they use our Hardware far worse but for east-west they are increasingly using VM firewalls so there's a choice that's the trend that we are saying justify I on when it comes to securing dynamic workloads you will have data centers sometimes with bare metal servers which are pretty static but as you move from Batman over close to virtualized data center to containers you will see that dynamic City popping up and then you'll be challenged to have the security catch up with that so you can use dynamic address to base policies now that is in well integrated with his Cisco's AC IEP geez to update your IP to tag mapping and what I mean by that is we have built this plug-in architecture so we have a dedicated Cisco ACI plug-in in Panorama you go to panorama tab and we have a demo for it but you'll be able to download that in less than 30 seconds install it and get this up and running that is called unmanaged mode of integration there is also managed mode of integration with device package but we highly recommend you to adopt on manage mode of integration because it's way more simple and you'll be able to get up and running and be go from zero to in production in just almost no time this ACA plugin allows you to write dynamic address group based policies on top of multiple cisco ACA constructs so Maurizio's showed you the tenant level hierarchy so you can write dynamic address groups on top of tenants application profiles EP g's and if you want to do micro segmentation then there is a construct in ACA called micro EPG so you can write dynamic address groups on top of micro YPG's so if you are steering the traffic between the micro apt is belonging the same bridge domain you'll be able to steal that traffic through the pharma and achieve micro segmentation at layer seven right it's super easy to configure and we'll show you in a demo if you have multiple data centers from the very same panorama you can manage up to 16 independent ACI clusters it's up to 16 independent data center sites with a CI you'll be able to manage from one panorama and that's really powerful well a picture can say thousand words but I believe demo can said ten thousand so with that I reserve why don't you run it to the demo okay so this is the so it's a recorded demo so you'll see the configuration steps and it's all based on these topology so the topology consists of three instances of panoramas sorry of yeah Palo Alto firewalls and then we here the security zones so you default gateway for the server's is so the service are spread across these three security zones and you will see these IP addresses in the demo so it's important to remember and this is this is showing that there's a contract between you know due to any P G's with redirect to to the Palo Alto firewalls visi any here means it's a concept of a CI where if you want have a contract for all DP G's you just use VZ n it's just an any any but the in the demo we just gonna show you the configuration and VZ n is just for you to know but maybe it's gonna be is useful but in fact we didn't say anything about it so let me just clarify for a second so if you imagine that you want to redirect all the traffic not just between two pages but between all the pages you want it to go through the firewall because that's your default security configuration an easy way to do it is to configure it with the busy any concept so it's one config when you say any xx it has to go through the firewall no matter what okay that's very convenient very convenient configuration option okay so let's take a look at the configuration here so I think the video will start yes it is very sorry so here we want to have redirect it says all TCP traffic within the BRF has to go through the parallel panorama and so how we do that here you have all the different endpoint groups a web app and database so you need to have a contract and the contract is it's called here any-any okay and so this is actually what I was mentioning before we use this busy any concept to say all traffic between all the PGS for TCP traffic send it to the firewalls and then there's another element of the contract that says for ICMP don't send it to the firewall you see this this entry is empty and this is the configuration of the service graph that's where you say I want to have this firewall between you know provider and consumer IP jeez now notice that it's mate so notice that this is made of three firewalls you saw they were like three viral instances so here we're looking at the Palo Alto configuration this is what you would enter to connect to a CI so this is the name of the IP address of the AP controller and the credentials and then if you look here this you see here the different Palo Alto VMs and then you could configure an address group type dynamic and and pull out which GP G's you want the address group to be based on so what this does is it allows panorama to pull the information from epic about which IP addresses are present in an endpoint group so you don't have to type the IP addresses manually and if these IP addresses are changing they are dynamically updated so this is an example these are the three P G's that you have in a CI that have been discovered by panoramas and you see that the IP address is inside of them are the ones that are present on the actual fabric in NCI so this allows communication by using the epic api's so that the security configuration security policies are based on the endpoint group names instead of being based on a list of IP addresses okay so this is the security configuration now we can try to connect from web to app here with HTTP and you see that the you know it's working because it's allowed but now we can modify the security policy on Panorama directly so we can remove HTTP so only ICMP will be allowed now but I simply anyway would not go through Panorama would not go through the Palo Alto Firewall okay so now this configuration issue is pushed okay okay now you see it's been updated so there's no HTTP allowed anymore so now if we try to pull that page it doesn't work anymore but now if I go to the App machine and try to connect to the database tier HTTP still allowed because the other access list entry was still allowing it on so this is all done without having to type any IP address it's all done by using the EPG information directly from the panorama configuration page so this is yeah so this is gives you an idea of what happens and what's you know there is the nemi communication so in panorama you see the security zones and you can just use the security zone directly into the snr is address group and use them in directly into the ACL configuration alright so in lieu of customer I have his slides where we will be talking about some of the real world deployment and this is real where customer it was they participated in our beta program they are now in production with our cisco ACA plugin and this is what their architecture looked like they had one tenant they had multiple tenants but let's just focus on one tenant they had next-gen data center tenant and they had one vrf under it n GD c v RF and they had three application profiles those three application profiles were openshift because they had cuban it is deployment so they had open shift EPG and they also had DMZ and non DMZ applications right three different application profiles under the same tenant same BRF different IP geez and they also had vm m domain integration because most of their servers were running on ESXi so they had been a member main integration with epic and they were well integrated with vmware on that front now Palo Alto Networks firewall was sitting at the perimeter north/south perimeter and it was connected is now connecting to epic but if you look at the use case they were trying to solve was hey how do we secure over north-south traffic and how do we really make it so dynamic and easy so that we don't have to update and worry about this Cuban Aires workloads coming up and going down and because Cuban areas were close the container workers will just come up will be spent up by application developers and will be spin down and the workloads that were mainly deployed here were internally by their developers so it was very difficult for them to keep firewalls state in sync with that epic state so here open shift load balancer whips were only listening to HTTP and https dmz also they had a five load balancer where it was listening to http and non DMZ load balancer f5 was on listening to on any ports there are two options the option one was out of box automation so customer literally wrote a script offline to pull epic every now and then every few seconds and every few minutes to find out how many endpoints have come or register under that EPG Kuban it is workloads or even vm workloads and then they would write panorama API calls to push those end points into panorama dynamic address scripts so it was really cumbersome and that means they had to do more coding it was out of box automation so it was the script that they were maintaining themselves and it took a lot of time it they also had the responsibility to maintain those scripts and it was delay time and administrative complexity was just too much the other solution when we developed the plug-in and they adopted it was they were now able to create those dynamic content scripts with the EPG Association right if both EPG and micro APG so they didn't have to code every time when when there is new enhancement because it is now Palo Alto Networks tech supported feature rules become effective as soon as endpoint is learnt in Asia and in the plug-in of panorama you can configure the interval at which panorama should pull a CI so that plug-in pulling interval was also configurable you can use anywhere between 30 seconds to 24 hours depending on how dynamic your environment is if you are not rolling out applications as fast then you can keep that time time a little bit high as well right and in in this case to a panorama downtime didn't affect the traffic by with only new learning the other use case was they wanted to have open ship servers accessing infrastructure tools like DNS and some of the common services DNS DHCP syslog and other tools the same with DMZ servers they all they wanted to make sure that it can access only common services and and not any other apps and if somebody want from the DMZ so it wants to access other apps and they will provision that only on demand but in non DMZ case where it is at more of a trusted domain they can allow any access again to solutions and they had two options with the earlier solution for multiple years they have been struck with that script which they developed in-house and they ran into the same challenges but when they deployed our plugin Cisco ACI II was loved Asya is dynamic endpoint learning was happening inside panorama the additional part that they really liked is we were not only pulling the tags for endpoint groups but we were pulling the tags also for application profiles so if you want to write less granular policies in Panorama not just at the EPG level but you want to just say tenant 1 between 10 and 2 this should be my epic security profile and policy you'll be able to achieve that - if you want to write it at an application level segmentation UK you can achieve that - right you don't have to do micro segmentation at EPG or micro ap0 you can level up a little high right the third use case was really interesting here they wanted to protect east-west traffic as well and I highly encourage you to consider east-west traffic protection as well with the next-gen firewall they had two - apps in the DMZ app they had default deny policy between between those apps in the DMZ application can talk only to the dependent apps on the DMZ but not on not anywhere else the specific force HTTP HTTP were allowed by using the contracts in Cisco ACI but they wanted to control the access between those apps where the communication so they were denying very where they can deny using a CI itself and that's our recommendation to if you can deny the traffic right there in the network by all means do that but when you start allowing the traffic that allowed traffic within the East West needs to go through the firewall for deep packet inspection so they had to option one use a CI layer for policies to to stop the traffic opposite it was administrative complex complexity was involved because there was the security team not they had to work with network team to change the contracts every now and then versus they had another option with our panorama integration where they just implemented Cisco acip BR so policy base redirect again yet another recommendation for you and firewall policies now but not just at layer four level but there were layer seven policies and the variable to leverage all the firewall features all the advanced next-gen security features with such as threat prevention and wildfire right so those were three use cases deployed in real time in real worlds engine situation some key takeaways from this session with this integration I think we have simplified not only just the operations but we have simplified the automation automation is usually done to simplify the manual tasks but in this case my customer eliminated their own automation the script that they were leveraging so we have simplified the automation we have automated the automation itself cisco ACI really provides that flexible and scalable service insertion architecture the real good feature that I like is the symmetric PBR so if it's symmetric PBR you can you can horizontally scale the firewalls and AC I can take care of load balancing the traffic and spraying it across so if you are used if you have dynamic environment you can use virtual firewalls and scale out again multiple options were proposed here use PBR there's our recommendation you can use now PBR in layer 1 layer 2 layer 3 mode and you also have operational mode level flexibility you can deploy the firewall in any of this mode and be as important consider VM series or next-gen firewall to protect your east-west traffic and scale the security on demand three next steps for you you can install panorama plugin today it's already generally available and I was talking to another customer who is here to go from zero to in production it will take you two minutes the installation of the SEO plugin itself is like consider 30 seconds you can connect to a pic in one minute and within one minute you will have all the tags pulled in so you'll be able to right start writing the dynamic address based policies and pre populate those security policies even before this traffic is steered so you can write the security policies irrespective of whether the firewall is in the path or not in the path and then you can go to the security network team and then have the epoch do the steering right and if there are any problem we are here to learn from your experience so do share with us what's your experience what issues you are running into we have another maintenance release coming up on Cisco ACI plug-in which will have very good cool features but it's part of roadmap so I'm not discussing it today but just wait for it you'll be able to upgrade the plug-in in a non-destructive manner plug-in upgrades in Panorama are non-destructively it will not cause any traffic disruption and I just had a session on micro segmentation but if you want to learn more about micro segmentation based practice with a CI or even in general watch the video the video will be also made available the session was ideal 8 o'clock but it's now recorded ok we are here to learn from your feedback that's how Maurizio and I grow professionally and personally from your feedback this is how we improve our presentation something that you like did not like what can be include more in the next session so please give us your feedback thank you so much and for Q&A I think we'll make ourself over thank you

Channel: Palo Alto Networks Ignite

Views: 2,293

Rating: 5 out of 5

Keywords: Automation/Orchestration, Datacenter/Private Cloud, Hybrid Cloud, Network Security, NGFW, VM-Series, Technology Integration

Id: GshejC_qsf8

Length: 52min 11sec (3131 seconds)

Published: Tue Dec 10 2019