Prisma AIRS: K8s & Container Protection

The PAN-CNI plugin installs as a DaemonSet in the kube-system namespace. It chains onto the cluster's existing CNI (Calico, Azure CNI, VPC CNI, etc.) without replacing it. When a pod is annotated for protection, PAN-CNI adds routing rules that redirect the pod's egress and ingress traffic through the AIRS firewall.

PAN-CNI traffic redirection through the AIRS firewall:

Two protection levels:

• VPC-level protection — secures all applications within the VPC. A single Helm chart covers the entire cluster. Annotate namespaces with paloaltonetworks.com/firewall=pan-fw.
• Namespace-level protection — provides granular control per application namespace with traffic steering inspection and CIDR-based rules. Separate Helm charts are generated for each protected namespace during deployment.

Private Kubernetes clusters (with no public API server endpoint) cannot be directly monitored by the firewall for IP-to-tag mappings. A Tag Collector Agent deploys as a separate firewall instance that connects to private cluster API servers, harvests IP-tag information for pods, services, and namespaces, and redistributes those tags to the AIRS firewall.

Tag Collector Agent architecture for private Kubernetes clusters:

For private cloud container platforms (OpenShift, Rancher), the PAN-CNI plugin integrates as a secondary CNI via Multus CNI chaining. This path requires Panorama management with PAN-OS 11.2.5 or later and Kubernetes plugin 3.0.4.

Key differences from public cloud deployments:

• Helm chart is sourced from the Prisma AIRS Helm GitHub repository, not the SCM Terraform download.
• A NetworkAttachmentDefinition must be deployed in each application namespace for Multus.
• Annotation uses k8s.v1.cni.cncf.io/networks=pan-cni instead of the standard PAN annotation.
• Single-arm deployment (trust interface only) with the firewall trust IP in values.yaml.

The AIRS AI Runtime Firewall must be deployed in the target cloud environment, connected to SCM or Panorama, and operational before configuring K8s protection.

1. Confirm the firewall is deployed by following the AIRS Network Intercept Core Guide through Phase 4 (Deploy Firewall).
2. Verify the firewall appears as Connected in SCM under Workflows → NGFW Setup → Device Management, or in Panorama under Panorama → Managed Devices → Summary.
3. Confirm AI Security Profiles are configured by completing Phase 5 (Security Config) of the Core Guide.

The Helm chart installation and pod annotation steps require local tooling and cluster administrative access.

1. Install Helm v3 on the workstation.
2. Confirm kubectl is installed and configured with credentials for the target cluster(s).
3. Verify cluster admin permissions:

   kubectl auth can-i create daemonset -n kube-system

   Copy
   The output must be yes.

Panorama-managed deployments require specific software versions for K8s protection features, including the Kubernetes plugin for IP tag harvesting.

1. Confirm Panorama software version is 11.2.5 or later.
2. Install Kubernetes plugin version 3.0.4 or later. Navigate to Panorama → Plugins and verify the installed version.
3. For IP tag harvesting (Phase 5), Kubernetes plugin version 3.1.0 or later is required.

The firewall needs static routes for pod and service subnets to properly route Kubernetes traffic. Gather these CIDRs from each target cluster before proceeding.

1. Extract the Terraform download:

   tar -xvzf <your-terraform-download.tar.gz>

   Copy
2. Navigate to the Helm directory based on protection level:
   • VPC-level:

     cd <unzipped-folder>/architecture/helm

     Copy
   • Namespace-level:

     cd <unzipped-folder>/architecture/helm-<app-name>

     Copy

     Namespace-level deployments generate separate Helm charts per protected namespace. Repeat the install process for each.

The values.yaml file contains cluster-specific parameters that must be verified before installation.

# Firewall trust interface IP Address for on-prem
endpoints: 10.101.255.253

# PAN CNI image
cniimage: gcr.io/pan-cn-series/airs/pan-cni:latest

# AI firewall trust CIDR (optional, reduces hops for east-west)
fwtrustcidr: ""

# Resource namespace name
namespace: kube-system

# Kubernetes Cluster ID (1-2048)
clusterid: 1

1. For VPC-level protection:

   helm install ai-runtime-security helm --namespace kube-system --values helm/values.yaml

   Copy
2. For namespace-level protection:

   helm install ai-runtime-security helm-<app-name> --namespace kube-system --values helm-<app-name>/values.yaml

   Copy

   Repeat for each namespace-specific Helm chart.

Run these verification commands to confirm all PAN-CNI components are running.

1. List Helm releases:

   helm list -A

   Copy

   Expected output:

   NAME                 NAMESPACE    REVISION  UPDATED                  STATUS    CHART                       APP VERSION
   ai-runtime-security  kube-system  1         2024-08-13 07:00 PDT     deployed  ai-runtime-security-0.1.0  11.2.2

   Copy
2. Check pod status:

   kubectl get pods -A | grep pan-cni

   Copy

   Pods named pan-cni-***** must show Running.

3. Check endpoint slices:

   kubectl get endpointslice -n kube-system | grep pan

   Copy
4. Check Kubernetes resources:

   kubectl get serviceaccounts -n kube-system | grep pan
   kubectl get secrets -n kube-system | grep pan
   kubectl get svc -n kube-system | grep pan

   Copy

Annotations tell PAN-CNI which pods to redirect through the firewall. Without annotation, pods are not protected.

1. For VPC-level protection — annotate each namespace:

   kubectl annotate namespace <namespace> paloaltonetworks.com/firewall=pan-fw

   Copy
2. For namespace-level protection — annotate all pods:

   kubectl annotate pods --all paloaltonetworks.com/subnetfirewall=ns-secure/bypassfirewall

   Copy
   Important: Annotation Value Naming

   The annotation value ns-secure/bypassfirewall is misleading: it does not bypass the firewall. This value instructs PAN-CNI to redirect the pod's traffic through the firewall for namespace-level subnet-based inspection. The name is a legacy artifact from the internal CNI routing logic.

3. For OpenShift — use the Multus CNI annotation instead:

   kubectl annotate namespace <namespace> k8s.v1.cni.cncf.io/networks=pan-cni

   Copy

   Also deploy the NetworkAttachmentDefinition in each application namespace:

   kubectl apply -f pan-cni-net-attach-def.yaml -n <target-namespace>

   Copy

Existing pods must be restarted after annotation for PAN-CNI to inject its routing rules. New pods created after annotation are automatically protected.

1. Restart pods in the annotated namespace:

   kubectl rollout restart deployment -n <namespace>

   Copy
2. Wait for pods to reach Running state:

   kubectl get pods -n <namespace> -w

   Copy

1. Confirm all PAN-CNI pods are running:

   kubectl get pods -A | grep pan-cni

   Copy

   Each node should have a pan-cni pod in Running state.

2. Verify namespace annotations:

   kubectl describe namespace <protected-namespace>

   Copy

   Annotations should include paloaltonetworks.com/firewall=pan-fw.

1. On the AIRS firewall CLI, check registered IP-to-tag mappings:

   show object registered-ip all

   Copy

   Expected output shows pod IPs with Kubernetes tags:

   registered IP            Tags
   --------------------------  --------
   10.111.22.108 *           "k8s.ns_gmp-system (never expire)"
                             "k8s.ns_gmp-operator (never expire)"
   10.111.19.125 *           "k8s.svc_metrics-server (never expire)"

   Copy
2. Verify the tag collector plugin status (if using SCM path):

   show plugins kubernetes status

   Copy

Generate test traffic between protected pods to confirm the firewall is inspecting K8s traffic.

1. Enter a secured pod:

   kubectl exec -it <pod-name> -n <secured-namespace> -- bash

   Copy
2. Send an HTTP request to another secured pod:

   wget http://<target-pod-ip>

   Copy
3. On the firewall CLI, verify the session:

   show session all filter source <source-pod-ip>

   Copy
4. Inspect the session detail to confirm the security policy rule is applied:

   show session id <session-id>

   Copy

   The output should show the security policy rule name (e.g., rule: allow-all-E_W).

1. Verify traffic object sub-interfaces on the firewall:

   show interface all

   Copy

   Sub-interfaces created by traffic objects should appear with the assigned zone.

2. Verify the traffic object zone appears in security policy matches for cluster-specific traffic.

The tag collector creates tags in these formats for Dynamic Address Group match criteria:

Tags are registered with (never expire) lifetime. They update dynamically as pods are created and destroyed.