9.4 CN-Series, AI Runtime Security, and Edge Deployment Options

9.4 CN-Series, AI Runtime Security, and Edge Deployment Options

The Integration and Automation domain (task 3.1) requires engineers to install the correct Palo Alto Networks deployment option for the target environment. The blueprint names five options: PA-Series, VM-Series, CN-Series, Cloud NGFW, and AI Runtime Security. The first three were covered in section 1.1 and Cloud NGFW was covered in section 9.1; this section completes the set with the containerized and AI-focused options.

---

CN-Series: Containerized NGFW for Kubernetes

CN-Series is the containerized form of the Palo Alto Networks NGFW, designed to run inside Kubernetes and container orchestration platforms. Where VM-Series deploys as a full virtual appliance at a network choke point, CN-Series deploys as containerized firewall pods that are placed directly in the cluster so they can inspect east-west pod-to-pod traffic that never leaves the cluster.

Deployment Models

• DaemonSet model: A firewall pod runs on every worker node (or every node labeled for inspection) so that all node traffic is inspected locally. This maximizes coverage and avoids hairpinning traffic to a central inspection point.
• Sidecar / Service-mesh model: The firewall is co-located with protected workloads to inspect specific application flows.
• CN-Series for Kubernetes vs CN-Series for OpenShift: Both use the same container image lineage; OpenShift adds tighter integration with the Red Hat OpenShift operator and SCC constraints.

Key Characteristics

CN-Series uses the same App-ID, Content-ID, and security profile stack as PAN-OS hardware and VM-Series so that policy authored once in Panorama or SCM applies consistently across all form factors.

CN-Series Architecture and Kubernetes Integration

CN-Series is deployed natively through Kubernetes orchestration. The firewall pods run as a DaemonSet, so a single kubectl apply or Helm chart deployment places a firewall pod on every labeled worker node in the cluster, and Kubernetes self-healing restarts any failed pod automatically. Traffic is steered to the firewall pods through supported Container Network Interface (CNI) plugins, which makes insertion transparent to applications — pods keep communicating using normal Kubernetes service discovery while the firewall inspects the flows in line.

CN-Series is supported across managed Kubernetes platforms — Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Red Hat OpenShift — and can also run in on-premises Kubernetes clusters. A dedicated CN-MGMT management pod handles the control plane for the firewall pods, and a Kubernetes plugin for Panorama (or the equivalent Strata Cloud Manager integration) translates native Kubernetes metadata such as namespace, labels, and service names into policy tags. This lets engineers write tag-based security policies that reference Kubernetes labels — for example, a rule that blocks traffic from a dev namespace to a prod-payments service — so that policy follows workloads as the scheduler reschedules pods across nodes.

Licensing and Scaling

CN-Series uses credit-based flexible licensing (Software NGFW credits) shared with VM-Series, so teams consume firewall capacity from a pool instead of licensing fixed appliances. Credits let security scale elastically with the cluster: as nodes are added for peak load, more firewall capacity is consumed; when nodes are removed, credits return to the pool. This consumption model aligns network-security cost with actual Kubernetes usage and is a common exam point because it differentiates CN-Series from the fixed-throughput PA-Series and the VM-Series bundle model. Because each firewall pod runs on a worker node, capacity scales horizontally with node count, and engineers size by the per-node session and throughput limits rather than by a single appliance's backplane.

---

AI Runtime Security

AI Runtime Security is the deployment option targeted at AI workloads. As organizations deploy large language models (LLMs), retrieval-augmented generation (RAG) pipelines, and AI agents that call external tools and APIs, the AI inference endpoint becomes a new attack surface that a traditional network firewall does not fully understand.

Threats AI Runtime Security Addresses

• Prompt injection and jailbreaks: Malicious instructions embedded in user input or retrieved content that cause the model to ignore guardrails.
• Model and data exfiltration: Attempts to extract training data, model weights, or sensitive RAG context through crafted queries.
• Toxic and malicious content: Generation or retrieval of harmful content, including malware payloads returned by tool calls.
• Vulnerable and malicious models: Detection of known-vulnerable or unapproved models being invoked by applications.
• Tool and agent abuse: Exploitation of the external tools, APIs, and data sources that AI agents can call.

How It Is Deployed

AI Runtime Security inspects the API traffic between users, applications, and AI models (whether self-hosted or consumed from providers) so that policy can permit, block, or alert on prompts, completions, and tool calls based on detected threats. It is delivered as a cloud-delivered security service and integrates with Strata Cloud Manager for policy, giving the same operational model as the rest of the NGFW portfolio.

Intercept Modes

AI Runtime Security is delivered through two protection modes that map to where AI traffic is inspected:

• Network Intercept: inline, real-time inspection of the network path in front of AI inference endpoints, covering all OSI layers 1–7. It sits like a traditional inspection point but understands AI prompt and completion semantics, blocking prompt injection, data leakage, model DoS, and toxic content in flight without changing the application.
• API Intercept: Security-as-Code embedded directly in the application. The application calls the AI Runtime API (for example, through the Python aisecurity SDK) to scan each prompt and model response programmatically, then acts on the returned allow/block/alert verdict before presenting output to the user. This mode suits AI providers and apps where inline network insertion is impractical or where inspection must happen at the application layer.

A related capability, AI Model Security, scans model versions before deployment to catch vulnerabilities such as arbitrary code execution during model loading, unsafe deserialization, and neural backdoors, so only vetted models reach production. Together these give defense-in-depth across the AI lifecycle — model scanning pre-deployment, and runtime inspection once the model is serving traffic — all managed from Strata Cloud Manager under the same policy and reporting plane as the NGFW portfolio.

---

Decision Matrix: Choosing a Deployment Option

---

Common Management Plane

A recurring exam theme is that the five deployment options are not five separate products with five separate management planes. They are five insertion points for the same PAN-OS inspection engine, all manageable from Panorama or Strata Cloud Manager. When architecting a hybrid deployment, engineers should plan the object, tag, and rulestack hierarchy so that shared policy descends cleanly to hardware, virtual, container, cloud, and AI inspection points.