Index › Software Firewalls: Containers & Kubernetes
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Software Firewalls: Containers & Kubernetes

← Back to full guide index

~6 min read
Prerequisites: Policy & Segmentation — CN-Series enforces the same policy model inside Kubernetes clusters.

Containers & Kubernetes Primer 33

Software Firewall (NGFW) course · Overview of Containerized Technology and Kubernetes

Learning objectives

  • Explain why containerized workloads need a different security model than VMs
  • Define the Kubernetes building blocks that CN-Series security policy hooks into (pod, node, namespace, cluster)

Kubernetes orchestrates many short-lived, IP-churning pods across a cluster of nodes — a security model built around static IPs and long-lived VMs doesn't map cleanly onto that.

Why

Containers are ephemeral by design: pods are created, scaled, and destroyed continuously, often with new IPs every time. East-west traffic between microservices inside a cluster also dwarfs traditional north-south traffic in volume. Legacy network security (IP-based rules, perimeter-only inspection) can't keep up with that churn or see traffic that never leaves the cluster.

How

A Kubernetes cluster groups nodes (VMs or bare metal running the container runtime) into a single control plane; each node runs pods (one or more co-located containers sharing network namespace), organized into namespaces for logical separation and labeled with metadata that a security product can use for policy instead of static IPs. This label/metadata model is exactly what CN-Series firewalls (see CN-Series Overview) hook into — using Kubernetes tags/labels as security-policy match criteria instead of addresses that change every time a pod restarts.
Kubernetes cluster nodes and pods with CN-Series firewall pods inserted for east-west traffic inspection.
Kubernetes cluster nodes and pods with CN-Series firewall pods inserted for east-west traffic inspection.

Pros

  • Label-based policy survives pod churn, unlike static-IP rules
  • Namespace segmentation gives a natural policy boundary that maps to how teams already organize workloads

Cons

  • Security teams unfamiliar with Kubernetes primitives face a real learning curve before container-native policy makes sense
  • Massive east-west traffic volume inside a cluster demands security tooling that scales horizontally with the cluster itself

Exam trap

Don't assume a perimeter NGFW in front of the cluster gives you visibility into pod-to-pod traffic — if both pods live on the same node/cluster, that east-west traffic never crosses the perimeter at all.
Self-check

Q1. A pod is rescheduled to a new node and gets a new IP. What lets your existing security policy keep matching its traffic without a manual rule update?

A: Policy written against Kubernetes labels/metadata rather than static IPs — the label travels with the pod regardless of which node or IP it lands on.

Q2. Why does east-west (pod-to-pod) traffic volume matter more in a Kubernetes cluster than in a traditional VM-based app?

A: Decomposing an app into microservices multiplies the number of intra-cluster calls needed to serve one request, so the traffic that needs inspecting is now mostly inside the cluster, not just at its edge.

Curriculum: Software Firewall (NGFW) course, "Overview of Containerized Technology and Kubernetes" lesson.

CN-Series Overview 34

Software Firewall (NGFW) course · CN-Series Firewalls Overview

Learning objectives

  • Explain what CN-Series is and why it exists alongside hardware/VM-Series NGFW
  • Identify the DevOps-friendly deployment tooling it's built around

CN-Series is Palo Alto's containerized firewall, purpose-built to bring Layer-7 App-ID-style visibility inside Kubernetes clusters, rather than only at the cluster's network edge.

Why

A perimeter firewall in front of a Kubernetes cluster can't see traffic between pods on the same node/cluster — exactly the traffic volume that's exploding as apps get decomposed into microservices. Security also needs to scale and deploy at the same pace as DevOps teams ship containers, not lag behind with manually-provisioned appliances.

How

CN-Series runs as Kubernetes-native workloads — deployed with Helm charts or Terraform (Helm is the recommended path) rather than as a bolt-on VM — giving full application-layer visibility into intra-cluster traffic. It's managed from the same Panorama console as every other Palo Alto firewall, so container security policy doesn't fork into a separate management silo. A Kubernetes plugin on Panorama tracks cluster license-token allocation and container activity automatically, since containers scale far faster than an admin could manually re-license instances.
CN-Series firewall pods inspecting east-west traffic between nodes and north-south traffic at the cluster edge, managed centrally by Panorama.
CN-Series firewall pods inspecting east-west traffic between nodes and north-south traffic at the cluster edge, managed centrally by Panorama.

Pros

  • Single Panorama pane of glass across hardware, VM-Series, and CN-Series
  • Helm/Terraform deployment fits existing DevOps/GitOps pipelines instead of fighting them
  • Sees intra-cluster east-west traffic a perimeter-only firewall never would

Cons

  • Requires real Kubernetes operational fluency from the security team (Helm, CNI plugins, service accounts)
  • Adds firewall pods to every node's resource footprint — a capacity-planning cost, not just a licensing one

Exam trap

CN-Series isn't a repackaged VM-Series image — it's deployed as Kubernetes-native container workloads (Helm/Terraform), and it's managed from the same Panorama console as hardware and VM-Series, not a separate console.
Self-check

Q1. Your DevOps team wants firewall deployment to fit into their existing GitOps pipeline. What CN-Series deployment method best supports that?

A: Helm chart deployment — it's the recommended, repeatable, versioned path that fits GitOps/CI workflows better than hand-applying YAML or Terraform alone.

Q2. Why does CN-Series need a Kubernetes plugin on Panorama specifically, rather than just standard firewall licensing?

A: Containers scale far faster than an admin can manually re-license instances, so the plugin automatically tracks cluster license-token allocation and container activity as pods come and go.

Source: cn-series (overview)

CN-Series Architecture 35

Software Firewall (NGFW) course · CN-Series Architecture

Learning objectives

  • Name the four CN-Series container images and what each does
  • Explain how traffic actually gets redirected from an application pod into the firewall

CN-Series splits the traditional single-appliance firewall into a distributed set of containers — a management plane, a dataplane, an init helper, and a CNI networking plugin — deployed per-node inside the cluster.

Why

A single monolithic firewall VM doesn't fit the Kubernetes operational model — it needs to be a set of containers that Kubernetes itself can schedule, scale, and restart like any other workload, while still functioning as one coherent firewall from a policy/licensing standpoint.

How

Four components, shipped as separate container images: CN-MGMT — the management plane, one per node, handling config/policy/logging (needs persistent storage for config and logs). CN-NGFW — the dataplane pod that actually inspects traffic, deployed as a DaemonSet (one per node) or as a Kubernetes Service. CN-INIT — an init container that bootstraps the management plane and establishes secure IPSec communication between CN-MGMT and CN-NGFW pods. CN-CNI — the networking plugin (often layered with Multus as a meta-CNI) that reconfigures application pods' network interfaces so their traffic is transparently redirected into the CN-NGFW pod on the same node before it leaves. All four are licensed and orchestrated centrally: a Kubernetes plugin on Panorama reads cluster resource labels via service-account credentials and turns them into Dynamic Address Groups and service objects usable directly in Security Policy.
CN-MGMT, CN-NGFW, CN-INIT, and CN-CNI containers working together on a Kubernetes node.
CN-MGMT, CN-NGFW, CN-INIT, and CN-CNI containers working together on a Kubernetes node.

Pros

  • DaemonSet placement (one dataplane per node) scales inspection capacity automatically with the cluster
  • IPSec-secured management-plane/dataplane channel keeps intra-firewall control traffic protected
  • Kubernetes labels feed directly into Dynamic Address Groups — no manual IP-based objects to maintain

Cons

  • Four moving container images (plus CNI/Multus interplay) is materially more complex to troubleshoot than one firewall image
  • Persistent volume requirements for CN-MGMT config/logs are easy to under-provision, especially in single-node PoC setups
  • Image/YAML version compatibility must be tracked carefully — mismatches are a common deployment failure

Exam trap

Remember which component does what: CN-MGMT is management/config/logging, CN-NGFW is the actual dataplane doing inspection, CN-INIT only bootstraps the IPSec channel between them, and CN-CNI is what physically redirects application-pod traffic into CN-NGFW. Exam questions like to swap these.
Self-check

Q1. Traffic from an application pod needs to reach the CN-NGFW dataplane pod on the same node before leaving. Which component makes that redirection happen?

A: CN-CNI — the networking plugin (often paired with Multus) that reconfigures application pods' network interfaces to transparently route traffic through CN-NGFW.

Q2. Why is CN-NGFW deployed as a DaemonSet rather than a single centralized instance?

A: A DaemonSet places one dataplane pod per node, so inspection capacity scales automatically as the cluster grows instead of becoming a single chokepoint.

Source: cn-series/getting-started/cn-series-firewall-for-kubernetes/components-required-to-secure-kubernetes-clusters-with-cn-series-firewall

CN-Series Deployment 36

Software Firewall (NGFW) course · CN-Series Firewall Deployment

Learning objectives

  • List what's required before deploying CN-Series into a cluster
  • Explain why Helm is the recommended deployment method

Deployment ties the architecture pieces together into a working cluster install: Panorama for management, the four container images pushed to your own registry, the matching YAML manifests, and a license auth code.

Why

Every piece (images, YAML, licensing) must be version-matched and correctly sequenced, or pods fail to come up or can't authenticate to the cluster or to Panorama — a manual, error-prone process that Helm exists specifically to standardize.

How

Prerequisites: Panorama running a compatible PAN-OS version (required for licensing and config management), the Kubernetes plugin installed on it, Helm 3.6+ if deploying via chart, and the four container images pulled, unzipped, and pushed to your own registry. Service-account YAML files let CN-MGMT/CN-NGFW authenticate to the cluster and the Kubernetes plugin authenticate for license/tag retrieval. Persistent volumes must be provisioned for CN-MGMT config/log storage (manual PV is PoC-only; dynamically provisioned volumes are the production recommendation). A license auth code tied to your CN-Series deployment profile on the Customer Support Portal licenses each CN-NGFW instance and any attached security subscriptions. Helm chart deployment is recommended over hand-applying the raw YAML files because it packages this whole sequence (images, configmaps, secrets, service accounts, CNI config) into one repeatable, versioned release.
Deployment flow from container registry through Helm chart install to Panorama registration and live policy enforcement.
Deployment flow from container registry through Helm chart install to Panorama registration and live policy enforcement.

Pros

  • Helm chart deployment is repeatable and versioned — a real advantage over manually sequencing a dozen YAML files
  • Auth-code-based licensing scales naturally as new nodes join the cluster

Cons

  • Manual persistent-volume setup is explicitly PoC-only — skipping dynamic provisioning in production risks losing config/log data
  • Environment-specific CNI choices (plain pan-cni vs. Multus variant, OpenShift's extra net-attach-def) add real deployment-target-specific complexity

Exam trap

Manual persistent-volume provisioning for CN-MGMT is explicitly called out as PoC-only — production deployments need dynamically provisioned volumes, or you risk losing config/log data.
Self-check

Q1. What four things must be version-matched and correctly sequenced before CN-Series will come up cleanly in a cluster?

A: Panorama's PAN-OS version (with the Kubernetes plugin installed), the four container images, the matching YAML manifests, and a valid license auth code.

Q2. Why is Helm chart deployment recommended over hand-applying the raw YAML files?

A: It packages the whole sequence — images, configmaps, secrets, service accounts, CNI config — into one repeatable, versioned release, instead of leaving admins to manually sequence a dozen interdependent files.

Source: cn-series/getting-started/cn-series-firewall-for-kubernetes/components-required-to-secure-kubernetes-clusters-with-cn-series-firewall; cn-series

Module Quiz

1. A security team currently manages firewall rules keyed to pod IP addresses inside a Kubernetes cluster. Within days, most rules stop matching the pods they were written for. What is happening, and what's the standard fix?

Pod churn breaks static-IP rules; label/metadata-based policy is the fix CN-Series relies on, since labels survive rescheduling and IP changes.

2. A company runs a perimeter NGFW in front of its Kubernetes cluster and assumes it has full visibility into all traffic touching the cluster's workloads. A later review finds large volumes of unlogged microservice-to-microservice traffic. What's the most likely explanation?

That traffic never crosses the cluster's network edge, so a perimeter device structurally can't see it — this is exactly the gap CN-Series is built to close.

3. Leadership asks why the organization needs CN-Series inside its Kubernetes clusters when a hardware NGFW already sits at the network edge. Which justification is accurate?

CN-Series exists specifically to inspect intra-cluster east-west traffic; it's managed from the same Panorama console as the perimeter firewall, not a replacement for it.

4. A platform team is choosing how to deploy CN-Series into a GitOps-driven cluster and also needs licensing to keep up as pods scale up and down automatically. Which two statements are correct? (Choose two.)

Helm is the recommended repeatable path (Terraform is also available, so it isn't Helm-only), and the Panorama Kubernetes plugin centrally tracks license-token allocation as pods churn.

5. During a CN-Series deployment review, an engineer needs to know which component is responsible for configuration, policy definition, and log storage — and therefore which component actually needs a persistent volume claim. Which is it?

CN-MGMT is the management plane handling config, policy, and logging, so it's the component that needs persistent storage.

6. As a Kubernetes cluster grows from 10 to 100 nodes, an architect wants inspection capacity to scale automatically with it rather than becoming a single chokepoint. Which CN-Series component and deployment pattern achieves that?

CN-NGFW is the dataplane; DaemonSet placement puts one inspection pod on every node, so capacity scales automatically instead of centralizing on one instance.

7. An application pod's traffic needs to reach the CN-NGFW dataplane pod on the same node before it leaves the cluster, without the application being rewritten or recompiled. What actually makes that redirection happen?

CN-CNI is the networking plugin that rewires pod networking so traffic transparently routes through CN-NGFW — no application changes, DNS tricks, or manual iptables required.

8. A security engineer wants Kubernetes namespace/pod labels to be usable directly as match criteria in Security Policy, without manually maintaining IP-based address objects as pods churn. What makes this possible, and where is it configured?

The Panorama Kubernetes plugin reads cluster labels via service-account credentials and turns them into Dynamic Address Groups, so policy references labels instead of static IP objects.

9. A team's proof-of-concept CN-Series deployment used a manually created persistent volume for CN-MGMT and it worked fine. Ahead of a production rollout, what should change, and why?

Manual PV setup is explicitly called out as PoC-only; production needs dynamic provisioning, or config/log data is at risk.

10. Before a CN-Series Helm deployment can succeed, several prerequisites must already be in place. Which three are genuine requirements? (Choose three.)

Images pushed to your own registry, service-account YAML for cluster/plugin authentication, and a license auth code are all real prerequisites — but Panorama must run a compatible PAN-OS version, not "any version."
← VPN & ConnectivitySoftware Firewalls: VM-Series & Public Cloud →