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