CN-Series building blocks- deploy the firewall manually
or using the Helm Package Manager for Kubernetes.
Where Can I Use This?
What Do I Need?
CN-Series 10.1.x or above Container Images
running PAN-OS 10.1.x or above version
Helm 3.6 or above version client
for CN-Series deployment using helm
The CN-Series firewall is the containerized next-generation firewall that provides
visibility and security for your containerized application workloads on Kubernetes
clusters. The CN-Series firewall uses native Kubernetes (K8s) constructs and Palo Alto
Networks components to make this possible.
deploy the CN-Series in your containerized environment, you must
download and deploy the various CN-Series deployment files.
init container generates certificates which are used for securing
communication between instances of CN-MGMT Pods and between CN-MGMT
pods and CN-NGFW pods.
PAN-CN-MGMT-SECRET—Allows Panorama to authenticate the firewalls
so that it can add each firewall as a managed device. The VM auth
key is required for the lifetime of the deployment. Without a valid
key in the connection request, the CN-Series firewall will be unable
to register with Panorama.
Distributed PAN-OS architecture with CN-MGMT and
—The management plane (CN-MGMT) and data
plane (CN-NGFW) of the containerized firewall are separate to enable
better runtime protection for applications and to support a smaller
footprint. The CN-MGMT and CN-NGFW are deployed using container
images and YAML manifest files with ConfigMap objects.
runs as a StatefulSet to ensure
that it has persistent volume and is exposed as a K8s service that
can be discovered using DNS in the Kubernetes environment. The CN-MGMT
provides fault tolerance and a single CN-MGMT pod can manage the
existing CN-NGFW pods in the event of a restart or a failure of
a CN-MGMT pod.
can be deployed as a DaemonSet
or as a Kubernetes Service. DaemonSet deployments suited for Kubernetes
environments with larger nodes, pods that require low latency, and/or
requires high firewall capacity. The CN-Series as a Kubernetes Service
is suited for Kubernetes environments with smaller nodes and/or
requires more dynamic firewalling.
, each instance of the CN-NGFW pod can secure
30 application pods running on the same node. This architecture
enables you to place the CN-NGFW DaemonSet pod on each node that
you want to protect workloads in a cluster, and a pair of CN-MGMT
pods can connect to and manage up to 30 CN-NGFW pods within a cluster.
For more information on limits, see CN-Series Performance and Scaling.
as a Kubernetes Service
instances of the CN-NGFW can be deployed on security nodes and application
pod traffic is redirected to an available CN-NGFW instance for inspection
PAN-CNI plugin for network insertion
—The PAN-CNI plugin is responsible for
the allocation of network interfaces on every pod, which enables network
connectivity to the CN-NGFW pod. The YAML files that enable you to deploy the
CN-Series include the PAN-CNI DaemonSet, which inserts the PAN-CNI plugin into
the CNI plugin chain on each node within the cluster. The plugin reads the
annotation on each application pod as it comes up to determine whether to enable
security and redirect traffic to the CN-NGFW pod for inspection as it ingresses
and egresses the pod.
Panorama for centralized management
functions as the hub for managing the configuration and licensing
of the containerized firewalls. It also hosts the Kubernetes plugin,
which enables monitoring of the Kubernetes clusters, and centralized
Security policy management. You can use a physical or virtual Panorama
appliance, and deploy it on-premises or in a public cloud environment.
Panorama must have network connectivity to the firewall management plane
pods (CN-MGMT) to ensure that it can license the (CN-NGFW) firewalls
and push configuration and policies using Panorama templates and
device groups. Palo Alto Networks recommends deploying Panorama
in an HA configuration.
You need standard Kubernetes tools
such as kubectl or Helm to deploy and manage your Kubernetes clusters,
apps, and firewall services. Panorama is not designed to be an orchestrator
for Kubernetes cluster deployment and management. Templates for
cluster management are provided by Managed Kubernetes providers.
You can also use the community-supported templates for deploying
CN-Series with Helm and Terraform.
Kubernetes Plugin on Panorama
Kubernetes plugin manages the licenses for the CN-Series firewall.
Licensing is based on the number of cores you choose to allocate
to CN-NGFW pods. Each CN-NGFW pod uses a license token, and the
tokens are managed locally on Panorama after you activate the auth
code and retrieve the specified number of tokens from the Palo Alto
Networks license server. As each CN-NGFW comes up on the Kubernetes
nodes, Panorama distributes the license tokens locally.
The Kubernetes plugin on Panorama also enables you to monitor your clusters and
leverage Kubernetes labels that you use to organize Kubernetes objects such as
pods, services, deployments and the associated identifying attributes, so that
you can create context-aware Security policy rules. The Kubernetes plugin
communicates with the API server and retrieves metadata in near realtime, to
enable visibility into the applications running within the cluster. The
Kubernetes plugin collects namespaces, services, and labels from your Kubernetes
clusters to create tags for the IP-address-to-tag mapping for the associated
objects within the cluster which can then be used in Security policies. For
details, see IP-Address-to-Tag Mapping of Kubernetes
It also collects information on the ports specified
in your application YAML and creates Service Objects.
While these tags and service objects are automatically
shared with the CN-NGFW pods in each cluster, you can also enable
sharing of the tags and service objects with hardware-based or VM-Series
firewalls. The tags become available as match criteria in Dynamic
Address Groups, which you can then use to secure traffic between
pods or namespaces, to an internet-exposed service, or outbound
Palo Alto Networks recommends deploying Panorama in an HA configuration so that the Panorama peer
continues to receive IP address updates in the event of a failure. If you deploy
a single instance of Panorama, in the event of a failure the traffic from any
existing applications pods are not impacted, and the current policies are
enforced on the CN-NGFW pods. When a new pod comes up, all the rules with the
source "ANY" will match to this new pod, and traffic from this new pod will be
allowed or blocked depending on your policy rules. For example, if there is an
Anti-Spyware policy rule to block outbound access from
source to the
outside world, then this rule will apply to the new pod, and the profile can
secure traffic. If there is a default
rule, then traffic from this
new pod will be denied.
You can use the Kubernetes plugin to distribute IP-address-to-tag mapping for
pods, nodes, namespaces, and services deployed within the Kubernetes cluster to
physical or VM-Series firewalls, even if you have not deployed CN-Series
firewalls in that cluster.