Software Firewalls: Containers & Kubernetes

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

The building blocks, and why each one exists:

• Node — a VM or bare-metal machine running the container runtime; a cluster is a group of these under one control plane. This is the physical/virtual substrate everything else runs on.
• Pod — one or more containers that are co-located and share a network namespace (so they share an IP and can talk to each other over localhost). This is the actual unit Kubernetes creates, destroys, and reschedules — and every time it does, the pod can land on a different node with a brand-new IP.
• Namespace — a logical grouping inside the cluster (commonly mapped to a team or environment) that gives a natural boundary for organizing and later securing workloads, well above raw IP addressing.

Why this all matters for security specifically: every pod carries metadata/labels (arbitrary key-value tags like app=payments or env=prod) that persist with the pod's identity regardless of which node it's rescheduled to or what IP it's assigned this time. This is exactly the model CN-Series firewalls (CN-Series Overview) hook into: security policy is written against those labels instead of IP addresses, so a rule keeps matching the right traffic even as the underlying pods churn continuously underneath it.

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

"Runs as" is the key phrase — not "runs next to." CN-Series isn't a VM firewall parked outside the cluster watching traffic go by; it's deployed as Kubernetes-native workloads — via Helm charts or Terraform, with Helm being the recommended path — meaning Kubernetes itself schedules, scales, and restarts the firewall exactly like it would any other containerized workload. That's what actually gets it application-layer visibility inside the cluster, on the same footing as the pods it's protecting.

Why it plugs into Panorama instead of getting its own console. If container security policy lived in a separate tool from hardware/VM-Series policy, an organization running a mixed environment (which is nearly everyone) would end up maintaining two disconnected policy sets that could drift out of sync. CN-Series avoids that by being managed from the exact same Panorama console as every other Palo Alto firewall — one policy model, one place to look, regardless of form factor.

Why licensing needs its own plugin instead of ordinary manual licensing. Containers can scale from a handful of instances to hundreds within minutes — far faster than an admin could manually track and re-license each new instance. A Kubernetes plugin on Panorama solves this by automatically tracking cluster license-token allocation and container activity as pods come and go, so licensing scales at the same speed the cluster does.

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, each solving one specific piece of "how do you make a firewall behave like a native Kubernetes citizen":

• CN-MGMT — "where does config/policy/logging actually live?" The management plane, one per node, handling configuration, policy, and logging. It needs persistent storage, because config and logs have to survive the pod itself being restarted — losing them on every restart would make the firewall unmanageable.
• CN-NGFW — "what actually inspects the traffic?" The real dataplane — this is the piece doing App-ID/Content-ID-style inspection. It's deployed as a DaemonSet (one instance automatically placed on every node) or as a Kubernetes Service, which is what lets inspection capacity scale automatically as nodes are added to the cluster, rather than being one central chokepoint everything has to funnel through.
• CN-INIT — "how do CN-MGMT and CN-NGFW trust each other?" An init container whose whole job is bootstrapping the management plane and establishing a secure IPSec channel between CN-MGMT and CN-NGFW — the same "authenticate before you trust" principle used everywhere else in this guide, applied to the firewall's own internal components talking to each other.
• CN-CNI — "how does application traffic actually reach the firewall in the first place?" The networking plugin (often layered with Multus, a "meta-CNI" that lets multiple network plugins coexist) that reconfigures an application pod's network interfaces so its traffic is transparently redirected into the CN-NGFW pod on the same node before it ever leaves. Without this piece, none of the other three components would ever actually see application traffic at all — it's the mechanism that makes inspection happen rather than just exist.

All four are licensed and orchestrated centrally rather than per-container: 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 — the same label-to-policy translation described in the previous section, now shown as the actual mechanism.

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

What has to exist before you even start:

• Panorama running a compatible PAN-OS version — required because Panorama is the licensing and config-management anchor for the whole deployment, not optional tooling.
• The Kubernetes plugin installed on that Panorama, and Helm 3.6+ if deploying via chart.
• The four container images (from the architecture above) pulled, unzipped, and pushed to your own registry — CN-Series doesn't pull directly from a public Palo Alto registry in a typical deployment, you host the images yourself.

Two separate trust relationships get set up via service-account YAML: one lets CN-MGMT/CN-NGFW authenticate to the Kubernetes cluster itself, and a second lets the Kubernetes plugin on Panorama authenticate back to the cluster for license and tag retrieval — two different directions of trust, both necessary.

Persistent volumes — why "it worked in my PoC" doesn't guarantee production safety. CN-MGMT's config/log storage needs a persistent volume to survive pod restarts. A manually-provisioned volume is explicitly called out as PoC-only: it's fine for a one-off test, but in production, nodes get replaced and pods get rescheduled onto different nodes routinely — a manually pinned volume won't reliably follow the pod, while a dynamically-provisioned one is designed to. Skipping this in production risks silently losing config/log data exactly when a node gets replaced.

Licensing flows through an auth code tied to your CN-Series deployment profile on the Customer Support Portal, which licenses each CN-NGFW instance plus any attached security subscriptions — the same auth-code model used elsewhere in the Palo Alto licensing ecosystem, just scoped to a Kubernetes deployment.

Why Helm specifically, and not just applying the YAML files by hand. A working CN-Series deployment isn't one file — it's images, configmaps, secrets, service accounts, and CNI config, all of which have to be version-matched and applied in the right order. Get that sequence wrong by hand and pods fail to come up or can't authenticate. A Helm chart packages that entire sequence into one repeatable, versioned release, which is what turns a fragile, error-prone manual process into something that can be reliably repeated across environments or rolled back if something goes wrong.