About rapatil

  In our previous blog Why Did We Build the CN-Series?, we discussed what is CN-series and how to deploy it natively using Helm Charts. Today, we're going to walk through prominent use cases.   There are three use cases in which customers most often employ CN-Series container firewalls. All three of these examples involve the insertion of threat protection—and other advanced security services—at the trust boundaries of cloud-native applications.     Use Case #1: East-West Layer 7 Traffic Protection     First up is the east-west traffic use case. Customers can use CN-Series to insert Layer 7 traffic protection and advanced threat-protection into their Kubernetes environments—this secures the allowed connections between two containerized applications of different trust levels; it can also secure the allowed connections between containers and other workload types.    Other micro-segmentation products provide granular protection at Layers 3 and 4 to block traffic between workloads that shouldn’t be able to communicate. The critical difference is that CN-Series can inspect and control allowed traffic at Layer 7 and enable our Threat Prevention subscription service to detect and stop threats that may be attempting to move laterally across the environment. The two types of solutions absolutely can be used together.   Read Part 1: What is CN-Series? now.     Use Case #2: #Outbound Traffic Protection     The second prominent use case is securing outbound traffic from container environments to the internet or developer resources hosted in sites like Github. Our URL-filtering service provides guardrails for developers and other users to ensure they aren’t connecting to potentially malicious sites. Our firewall’s ability to inspect traffic content, coupled with our DNS Security service guard against data exfiltration, ensures our customers’ critical information stays in the environment where it belongs.   While some customers may prefer to use their perimeter firewalls in their on-prem data centers, customers running Kubernetes environments in the public cloud will require CN-Series to solve this use case. Here is a quick video demonstration,  Outbound Traffic Protection Using CN-Series Container Firewall , for your reference.       Read Part 2: Why Did We Build the CN-Series? now.     Use Case #3: Inbound Threat Prevention     Last but not least is the traditional inbound perimeter use case. Network security teams can prevent threats riding on inbound traffic to the container environment with our Threat Prevention and Wildfire malware analysis services. Again, depending on the customer’s environment and overall architecture they may elect to do this with their perimeter firewalls on-prem. Still, a CN-Series or VM-Series would be required to do this in public cloud environments.   All three of these use cases can be addressed regardless of whether the apps are hosted in an on-prem data center or a public cloud.   To summarize, CN-Series container firewalls deliver:   Inline network security to improve visibility and protect Kubernetes namespace boundaries with security services such as threat protection and URL filtering. Flexible configuration and deployment options to allow administrators to automate security deployment and leverage the autoscaling capabilities of Kubernetes. Cloud and on-premises support to give network architects the tools to design public, private, and hybrid cloud architectures. Centralized security management via Panorama to unify control of hardware and virtual Palo Alto Network firewalls as well as native security provided by Amazon Web Services, Google Cloud, Microsoft Azure Kubernetes Services and OpenShift.   Find more information about Secure Your Kubernetes Future with CN-Series Container Firewalls.   Find the entirety of the three-part CN-Series by Raj Patil on our CN-Series Articles page. ... View more

In my previous article,  "Why Did We Build the CN-Series?," we discussed the why behind the development of the CN-Series in a world where cloud-native adoption and containerized applications are on the rise.    Now, we're going to go over what a CN-Series firewall actually does, its functions, and how it can help NetSec teams secure Kubernetes workloads.    CN-Series Container Firewalls for Kubernetes deliver all of our PA-Series (hardware NGFW) and VM-Series (software) firewalls’ capabilities in a container form factor. You can deploy our cloud-delivered security services on top of the CN-Series firewalls, just like our other firewall form factors. This solution gives you the ability to deploy Layer 7 network security and threat protection in your Kubernetes clusters for advanced protection and compliance.   CN-Series has been deeply integrated with Kubernetes for complete visibility and context and ensures that the firewall is automatable and scalable to accommodate DevOps workflows.   So what exactly do you get with CN-Series?   Specifically, CN-Series provides customers with visibility and control over their Kubernetes traffic. You will gain a contextual understanding of Kubernetes constructs, like namespaces and tags, to define security policies.   CN-Series also provides deeper traffic visibility than any other firewall form factor. For instance, it can overcome the challenge to  identify the specific pod that traffic originates from, as we discussed in my previous article on the CN-Series. It means that you can write security policies more granularly—at the application-level rather than at the cluster-level.    CN-Series firewalls are managed in Panorama, using the new Kubernetes plugin. A consistent management solution to incorporate Kubernetes context into integrated policies, which provide broader network security posture.   As I mentioned before, the deep integration we’ve built between CN-Series and Kubernetes ensures that the firewalls can be deployed and configured seamlessly as part of your DevOps team’s workflow. For those of you using Helm to manage your Kubernetes deployments, we’ve built a Helm chart for CN-Series.   Here is a quick demonstration  of how to deploy CN-Series via Helm Charts.       CN-Series — Distributed deployment mode in PANOS 10.0   In our PANOS 10.0 release, you have a CN-Series firewall deployed on each node as a Daemon set within your K8S environment to provide maximum visibility and control.   CN-Series deployment     Technically, the firewalls deploy two sets of pods: one for the management plane (CN-MGMT) and another for the firewall data plane (CN-NGFW). The firewall data plane runs as a daemon set, and the management plane simply runs as a Kubernetes service.   Of course, we also have Panorama represented here since that’s where CN-Series is managed from. The plugin is continually pulling information from Kubernetes and feeding it into Panorama.    What’s new in PANOS 10.1 for CN-Series?   Starting with the PANOS 10.1 release, Palo Alto Networks adds a new fw-as-a-k8s-service deployment mode to augment the fw-as-a-daemon-set mode.   With CN-Series NGFW running as a k8s service, customers will no longer need to deploy the CN-NGFW on every application node. Instead, you can have dedicated nodes (let’s call them Security nodes ) on which all CN-NGFW firewalls will be deployed. Traffic redirection between Application Pods and CN-NGFW happens via secure VXLAN encapsulation.   CN-Series cluster mode     When to go for Daemon set vs. K8s Service deployment?   Daemon set deployment mode needs at least one CPU core and 2G memory per CN-NGFW firewall per node. So, customers with a large footprint and/or high firewall-capacity demands will go for Daemon set deployment for compliance and risk mitigation use cases.  However, the second set of customers with smaller nodes and/or small firewall capacity needs and looking for securing a subset (e.g. database traffic) through CN-Series firewalls will most likely adopt the CN-Series as a k8s service mode (PANOS 10.1) or Cluster mode deployment.   These customers would like to start small (limited firewall capacity with minimum resource needs) and dynamically increase/decrease the firewall capacity as the need changes while minimizing the disruption to the traffic. These customers will benefit from having the ability to run firewall as a shared k8s service, just like any other k8s application, where they could start with 1 or 2 pods and automatically scale the number of firewall pods up/down when the traffic is going through the firewall service increases/decreases.    CN-Series Autoscaling with Horizontal Pod Autoscaler (HPA) feature   Starting with the 10.1 release, CN-Series in cluster mode will also support the auto-scaling functionality based on standard or custom metrics.  For the standard metrics, customers can scale their Management Pods and the Dataplane Pods based on average CPU or memory utilization across all Pods.   I hope I was able to provide enough information on CN-Series to get you started. In my third and final article, I’ll go over some of the primary use-cases of CN-Series.   Find more information, visit Palo Alto Networks' page on  CN-Series Container Firewalls for Kubernetes.    ... View more

Cloud-native adoption is on the rise.   If you haven’t already started thinking about the impact of containers on your network security (NetSec) posture, now’s a good time to start. Gartner predicts that most organizations will be running multiple containerized applications in production in the next three years.                                                                                Organic growth of container environments is creating the following challenges for NetSec teams:   Challenges for NetSec Team   1. Lack of visibility and control   You can’t protect what you can’t see. NetSec teams need the same level of visibility and control over their cloud-native environments over their physical and virtual environments. While cloud-native security tools provide several fantastic things to protect containerized applications, the one thing they do not offer is comprehensive Layer 7 network security and threat prevention.   2. Inconsistent tools and management   Our network security customers are already overwhelmed with too many tools. The last thing you need is additional point solutions to solve this problem. Furthermore, attempting to manage network security across multiple tools and management consoles often leads to gaps in policies and increases the overall risks.   3. Lack of automation and scalability Whatever controls Network Security does end up deploying need to be highly automated and scalable as part of a DevOps workflow, or the DevOps and Application teams won’t allow them to have used them in the first place. A security tool cannot slow down the speed of development.   At this point, you may be asking yourself, “But what about virtual firewalls? Can’t they be deployed at the edge of the Kubernetes cluster (environment for visibility and control)?”   You’d be right; we could technically deploy virtual firewalls or even hardware firewalls at the edge of container environments. But the fact that these firewalls are deployed outside the K8s cluster means their visibility and control is limited in some crucial ways.       Figure 1: NetSec Challenges for managing K8s Clusters   The most significant gap is that a firewall outside a cluster cannot determine the specific traffic source in the container environment. To understand this, we need to understand a bit of how Kubernetes and containers work.   In the container cluster shown in Figure 1, you can see two applications deployed: Ordering and Payments. The little hexagons represent “pods.” You can think of Pods as components of an application. The red pods are all components of the Payments app; the green pods are part of the ordering app.   A Node is a worker machine, a VM, or a physical machine that contains services to run the pods.   Now, due to the way Kubernetes works, pods from different applications can leverage the same node to run.   This how we arrive at the visibility problem for a firewall located outside of the cluster. Each pod’s IP address gets translated to the Node IP Address. A firewall outside the cluster can only see the node IP address, not the individual pod’s IP address.   It means that the firewall can’t resolve whether the traffic originated from the Payments app or the Ordering app. The more applications deployed in the cluster, the more complicated this gets.   I should mention that this visibility challenge isn’t the only limitation of other firewall form factors. A firewall located outside the K8s cluster also lacks critical context about the container environment itself.    For instance, the firewall has no concept of namespaces, which is a logical construct that helps delineate between applications in Kubernetes environments. The namespaces are represented in this diagram (figure 1) by the red and green labels. A network security engineer could write a policy that explicitly allows traffic from the Payments application namespace to the database and back in an ideal world. The namespace is the crucial boundary where most organizations want to enforce Layer 7 network security and advanced threat protection, so a firewall must pull this context from the environment and use it.   And that’s why we have created the industry’s first CN-Series container firewall. ... View more

Securing an airport and securing your cloud-native applications have more in common than you may realize – and two essentials of airport threat prevention nicely illustrate why virtual and container NGFWs are vital for security in the cloud. As digital transformation drives you to move crown jewel applications to public clouds and containers, you need to use the same layered security approach airports typically provide.    Want to learn more? Check it out. ... View more

Container adoption is on a serious rise,  which is why we’re releasing  CN-Series , the containerized version of our ML-Powered Next-Generation Firewall (NGFW), designed specifically for Kubernetes environments. It’s a significant development because, according to  Gartner , in the next three years,  the vast majority of organizations will be running multiple containerized applications in production.    Learn more here! ... View more

Both VM-Series and CN-Series firewalls can be used to protect container environments. The major difference between the two is the granularity of visibility and control delivered by the CN-Series. VM-Series firewalls can enforce cluster-level security policies, which makes them good for basic perimeter security of an entire cluster.   But in many circumstances, you may want to inspect traffic within the cluster for threats or for compliance reasons, or you might want to enforce tighter segmentation between application components hosted within the same cluster. In these circumstances, CN-Series firewalls provide the granular visibility and control over traffic between nodes that will enable these types of use cases.   Learn more here. ... View more

As their names suggest, the major difference between a container firewall and a virtual firewall is the fact that container firewalls are deployed as containerized services and virtual firewalls are deployed as virtual machines. By deploying as a container, container firewalls are more easily integrated into containerized environments, giving them deeper visibility and control over the traffic that traverses the container environment. Their deployment can also be orchestrated using the native tools for managing containerized environments, allowing them to be easily incorporated into existing DevOps workflows.   Virtual firewalls are better suited for deployment into virtualized environments, including public and private clouds. They can be used to enforce perimeter security in public clouds as well as for segmentation to inspect east-west traffic for threats.   Learn more here. ... View more

Inserting virtual appliances in public cloud environments just got a great deal easier, thanks to Amazon Web Services (AWS) recently announcing the general availability of the integration between VM-Series virtual firewalls and the new AWS Gateway Load Balancer (GWLB) . It’s an exciting development because this latest integration provides customers with massive security scaling and performance improvements while eliminating the complexities of inserting virtual appliances in public cloud environments. As many of our customers will be delighted to learn, GWLB makes it easy to deploy, scale, and manage your third-party virtual appliances on Amazon Web Services (AWS).   Integration resolves significant scaling and deployment challenges When it comes to deploying VM-Series firewalls in AWS, customers typically leverage an AWS Transit Gateway deployment. Like most customers, you probably connect the spoke VPCs with application workloads to the AWS Transit Gateway- and then deploy the VM-Series firewalls in dedicated security VPCs and connect to the same AWS Transit Gateway. But without these GWLB capabilities, customers face challenges that slow deployment and get in the way of performance and consistent security. In particular, two challenges need to be addressed to attain optimal speed, performance, and ongoing threat protection. Here are some of the tradeoffs associated with a design without Gateway Load Balancer: Challenge # 1 - Scale and Throughput Performance Until now, you had two connectivity options to route your outbound and east-west traffic through the VM-Series firewalls in your transit gateway environment: You could deploy VM-Series with encrypted tunnels using AWS Transit Gateway VPN attachments (see Figure 1).  You could deploy VM-Series in active-passive HA mode using AWS Transit Gateway VPC attachments. The first option provides a scale using equal-cost multi-path routing (ECMP) and multiple VPN attachments, but each VPN attachment offers a limited throughput of 1.25 Gbps . The second option uses VPC attachments that provide up to 50 Gbps of throughput but do not scale beyond a single active VM-Series firewall (per AWS Availability Zone).         Figure 1: c urrent transit gateway deployment models with VM-series may force customers to make tradeoffs between visibility, scalability, and performance.   Challenge # 2 - Visibility and Centralized Firewall Management A similar tradeoff exists for inbound traffic protection. Like most customers, you likely use a “sandwich” architecture that forces all your inbound application traffic to flow through an inbound security VPC. This inbound security VPC hosts an auto-scaling firewall stack for threat prevention (see Figure1). While this architecture enables you to manage firewalls and security policies centrally, it also requires the firewalls to apply source address translation (SNAT) on the traffic to maintain flow symmetry, thereby obfuscating the source’s identity to your applications. The integration of VM-Series virtual firewalls with the GWLB alleviates the above tradeoff concerns. This new integration shown in figure 2 enables you to use native AWS networking constructs – such as VPC attachments – to scale your VM-Series firewalls dynamically to match your inbound, outbound, and east-west traffic demands.    Figure 2. AWS Gateway Load Balancer simplifies VM-Series virtual firewall insertion at a higher scale and throughput performance for inbound, outbound, and east-west traffic protection.   The VM-Series firewall integration with GWLB offers the following benefits: Simplified connectivity: Easily insert an auto-scaling VM-Series firewall stack in the outbound, east-west, and inbound traffic paths of your applications. VM-Series and the GWLB use the GENEVE encapsulation to keep your traffic packet headers and payload intact, providing complete visibility of the source’s identity to your applications – In other words, no more SNAT.  Performance at scale: Scale your traffic across multiple VM-Series firewalls at higher throughput by using AWS native networking constructs and AWS Transit Gateway VPC attachments. You no longer need encrypted tunnels for east-west and outbound traffic inspection – In other words, no IPsec tunnel overhead. Cost-Effective: Reduce the number of firewalls needed to protect your AWS environment and consolidate your overall network security posture with centralized security management. Get the GWLB Integration Details To learn more about the benefits of this integration, take a look at these helpful resources: Watch the overview video  for an understanding of what you’ll gain from the integration     See the in-depth demo video  highlighting VM-Series with Gateway Load Balancer deployment using Cloud Formation Templates     And to begin realizing these benefits in your AWS environment today, you can start a trial of VM-Series on AWS from the AWS Marketplace . And don’t forget to check our  Palo Alto Networks Github repository for the latest VM-Series resources, which will help you deploy this new solution - and save your organization time and effort. ... View more