CN-Series Core Building Blocks

• CN-Series Deployment Files—to deploy the CN-Series in your containerized environment, you must download and deploy the various CN-Series deployment files.
  • PAN-CN-MGMT—The 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-CONFIGMAP
  • 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.
  • PAN-CN-NGFW
  • PAN-CN-NGFW-CONFIGMAP
  • PAN-CNI
  • PAN-CNI-CONFIGMAP
  • PAN-CNI-MULTUS
• Distributed PAN-OS architecture with CN-MGMT and CN-NGFW pods—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.
• CN-MGMT 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.
• CN-NGFW 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.
  • When deployed as a DaemonSet, 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.

  • When deployed 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 and enforcement.

• 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—Panorama 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—The 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 Attributes.
  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 connections.
  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 any 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 Deny 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.