>
    Strata Copilot
    Configure Strata Cloud Manager to Secure VM Workloads and Kubernetes Clusters
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma AIRS
    3. Administration
    4. Deploy Prisma AIRS AI Runtime: Network Intercept in Public Clouds
    5. Configure Strata Cloud Manager to Secure VM Workloads and Kubernetes Clusters
    Download PDF
    Prisma AIRS

    Configure Strata Cloud Manager to Secure VM Workloads and Kubernetes Clusters

    Table of Contents

    Configure Strata Cloud Manager to Secure VM Workloads and Kubernetes Clusters

    Prisma AIRS AI Runtime: Network intercept post-deployment configurations in Strata Cloud Manager and cloud to protect VM workloads and Kubernetes clusters.
    Where Can I Use This?What Do I Need?
    • Secure VMs and Kubernetes
    This section covers the configurations you need to secure your VM workloads/vNets and Kubernetes clusters, and route traffic after you apply the Prisma AIRS AI Runtime: Network intercept deployment Terraform template in your cloud environment.
    In this section you will:
    • Configure the following in Strata Cloud Manager:
      • Interfaces
      • Zones
      • NAT Policy
      • Routers
      • Security Policies
    • Secure VM workloads only for public clouds
    • Secure Kubernetes clusters in private and public clouds
    • Install a Kubernetes application with Helm
    • (Optional) Configure labels in your cloud environment for manual deployments.
      The Prisma AIRS AI Runtime: Network intercept deployment Terraform you generate from Strata Cloud Manager, automatically adds the required labels to organize your Prisma AIRS AI Runtime: Network intercept. For manual deployments, ensure you have the following labels (key-value pairs) in your Terraform template.
      • Add the following labels (key-value pairs) under Tags in the Terraform template file under your downloaded path `<azure|aws-deployment-terraform-path>/architecture/security_project/terraform.tfvars`. The value of these keys must be unique.
      • For GCP: `paloaltonetworks_com-trust` and `paloaltonetworks_com-occupied`.
      • For Azure and AWS: `paloaltonetworks.com-trust` and `paloaltonetworks.com-occupied`.
      • Ensure the network interface name in the security_project Terraform is suffixed by `-trust-vpc`.
    Prisma AIRS AI Runtime: Network intercept is only supported for public clusters on GCP, Azure, and AWS cloud platforms and a few private clouds such as OpenShift, ESXi, and KVM.
    Prerequisites
    • Deploy Prisma AIRS AI Runtime: Network Intercept in Public Clouds specific to your cloud to Save and Download the Terraform template.
    • Unzip and navigate to the `<unzipped-folder>` that has the following structure:
      
|____architecture
    |____LICENSE
    |____README.md
    |____security_project
    |____application_project
    |____helm
|____modules
    • (Optional) Enable SSL/TLS decryption on Prisma AIRS AI Runtime: Network intercept to decrypt traffic between AI applications and AI models:
      The decryption helps you to detect and enforce AI security protection.
      These steps involve creating a decryption policy and exporting the Root CA from Strata Cloud Manager.
      • Log in to Strata Cloud Manager.
      • Navigate to Manage→ Configuration → NGFW and Prisma Access→ Security Services → Decryption.
      • Add a new decryption policy rule, or modify an existing one.
      • Configure the source and destination zones.
      • Under "Action and Advanced Inspection", set the action to decrypt.
      • Select the decryption type to SSL Forward Proxy.
      • Select a Decryption Profile to perform additional checks on traffic that matches the policy rule.
      • Navigate to Manage→ Configuration → NGFW and Prisma AccessObjects → Certificate Management.
      • Select Root CA and click Export Certificate.
      • Push the changes to the Prisma AIRS AI Runtime: Network intercept and wait for the push to complete.

    GCP

    Prisma AIRS AI Runtime: Network intercept post-deployment configurations in Strata Cloud Manager and GCP to protect VM workloads and Kubernetes clusters.
    Where Can I Use This?What Do I Need?
    • Secure VMs and Kubernetes Clusters in GCP
    1. Log in to Strata Cloud Manager.
    2. Configure Prisma AIRS AI Runtime: Network intercept interfaces:
      1. Navigate to Manage→ Configuration → NGFW and Prisma Access.
      2. Select Device Settings → Interfaces.
      3. Set the Configuration Scope to your AI Runtime Security folder.
      4. In the Ethernet tab:
        Configure a Layer 3 Interface for eth1/1 and eth1/2:
        • Interfaces: eth1/1 and eth1/2
        • Location: Specify location if applicable
        • Interface Type: Layer3
        • IP Address: Dynamic (DHCP Client)
      5. Select the Loopback tab to configure the Loopback interface:
        • In IPv4s, enter the ILB (Internal Load Balancer) private IP address
        • Set Security Zone to trust for eth1/2 and untrust for eth1/1
        • Ensure VR (Virtual Router) is set to default or the same as eth1/2
    3. Create zones. Select Manage→ Configuration → NGFW and Prisma Access → Device Settings → Zones.
    4. Configure a Logical Router:
      • Create a Logical Router and add the Layer 3 interfaces (eth1/1 and eth1/2).
      • Configure a Static Route with the ILB static IP addresses for routing. Use the trust interface gateway IP address.
    5. Add a security policy (Manage→ Configuration → NGFW and Prisma Access → Security Services → Security Policy → Add Rule).
    6. Set the action to Allow.
      Ensure the policy allows health checks from the GCP Load Balancer (LB) pool to the internal LB IP from Strata Cloud Manager. Check session IDs to ensure the firewall responds correctly on the designated interfaces.

    Configurations to Secure VM Workloads

    1. Configure Static Routes for VPC endpoints.
      1. Log in to Strata Cloud Manager.
      2. Navigate to Manage→ Configuration → NGFW and Prisma Access → Device Settings → Routing → Logical Routers.
      3. For VPC Subnet:
        • Edit the IPv4 Static Routes and add VPC IPv4 range CIDR subnets route.
        • Set the Next Hop as eth1/2.
        • Set the Destination as the trust subnet gateway IP from Strata Cloud Manager.
        • Update the static route.
        Save the Logical Router.
    2. Log in to Strata Cloud Manager.
    3. Select Manage→ Configuration → Push Config and push the policy configurations to Prisma AIRS AI Runtime: Network intercept.

    Configurations to Secure Kubernetes Clusters

    1. Add pod and service IP Subnets to Prisma AIRS AI Runtime: Network intercept trust firewall rules:
      1. Get the IP addresses for pod and service subnets:
      1. Go to Kubernetes Engine -> Clusters.
      2. Select a Cluster and copy the Cluster Pod IPv4 and IPv4 Service range IP addresses.
    2. Follow the AI network intercept deployment in GCP to save and download the Terraform template.
    3. Edit the Terraform template to allow the following IP addresses in your VPC network firewall rules:
      • Navigate to the `<unzipped-folder>/architecture/security_project` directory.
      • Edit the `terraform.tfvars` file to add the copied IP addresses list to your `source_ranges`.
        
firewall_rules = {
      allow-trust-ingress = {
        name             = "allow-trust-vpc"
        source_ranges    = ["35.xxx.0.0/16", "130.xxx.0.0/22", "192.xxx.0.0/16", "10.xxx.0.0/14", "10.xx.208.0/20"] # 1st 2 IPs are for health check packets. Add APP VPC/Pod/Service CIDRs
        priority         = "1000"
     
       allowed_protocol = "all"
        allowed_ports    = []
      }
}
    4. Apply Terraform:
      terraform init
terraform plan
terraform apply
    5. Add static routes on the logical router for Kubernetes workloads:
      1. Log in to Strata Cloud Manager.
      2. Select Configuration → NGFW and Prisma Access → Device Settings → Routing → Logical Routers.
      3. Configure Static Routes for the pod and service subnets for the Kubernetes workloads:
        Pod Subnet:
        • Edit the IPv4 Static Routes and add a route with the Pod IPv4 range CIDR.
        • Set the Next Hop as eth1/2 (trust interface).
        • Set the Destination as the trust subnet gateway IP from Strata Cloud Manager.
        Service Subnet:
        • Edit the IPv4 Static Routes add a route with the IPv4 Service range CIDR.
        • Set the Next Hop as eth1/2 (trust interface).
        • Set the Destination as the trust subnet gateway IP from Strata Cloud Manager.
    6. Add source NAT Policy for Outbound Traffic:
      1. Log in to Strata Cloud Manager.
      2. Select Configuration → NGFW and Prisma Access → Network Policies → NAT.
      3. Create or modify a source NAT Policy:
        • Source Zone: Trust
        • Destination Zone: Untrust (eth1/1)
        • Policy Name: trust2untrust or similar.
    7. Configure NAT settings:
      Interface Address Section:
      • Set the Interface to eth1/1. (The translation happens at eth1/1).
        If needed, create a complementary rule for the reverse direction (for example, untrust2trust).
    8. Log in to Strata Cloud Manager.
    9. Select Configuration → Push Config and push the policy configurations to Prisma AIRS AI Runtime: Network intercept.
      If you have a Kubernetes cluster running, follow the section to install a Kubernetes application with Helm.

    Secure a Kubernetes Application with Helm

    This section covers how to install and configure the Helm chart to secure your Kubernetes applications based on the protection level you selected during deployment.
    The Helm chart installation process and directory structure vary depending on whether you selected VPC-level protection or namespace-level protection with traffic steering inspection. VPC-level protection secures all applications within the VPC, while namespace-level protection with traffic inspection provides granular control over specific application traffic flows and CIDR-based inspection rules.
    Your deployment configuration determines the specific Helm chart structure and commands required for your environment.
    1. Navigate to the downloaded tar file and extract the contents:
      tar -xvzf <your-terraform-download.tar.gz>
    2. Navigate to the appropriate Helm directory based on your deployment configuration:
      • For VPC-level security:
        cd <unzipped-folder>/architecture/helm
      • For namespace-level security with traffic steering inspection:
        cd <unzipped-folder>/architecture/helm-<complete-app-name-path>
        • Navigate to each Helm application folder. When you configure traffic steering inspection, separate Helm charts are generated for each protected namespace, allowing granular security policies per application.
        • GKE Autopilot clusters do not support Helm deployments due to restrictions on modifying the kube-system namespace.
    3. Install the Helm chart using the appropriate command:
      • For VPC-level security:
        helm install ai-runtime-security helm --namespace kube-system --values helm/values.yaml
      • For namespace-level security with traffic steering inspection:
        helm install ai-runtime-security helm-<complete-app-name-path> --namespace kube-system --values helm-<complete-app-name-path>/values.yaml
        Repeat this command for each namespace-specific Helm chart generated during the deployment process.
      This creates a container network interface (CNI), but doesn’t protect the container traffic until you annotate the application `yaml` or `namespace`.
    4. Verify the Helm installation: 
      #List all Helm releases
helm list -A

#Ensure the output shows your installation with details such as:
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
    5. Check the pod status: 
      kubectl get pods -A
#Verify that the pods with names similar to `pan-cni-*****` are present.
    6. Check the endpoint slices: 
      kubectl get endpointslice -n kube-system

#Confirm that the output shows an ILB IP address:
NAME             ADDRESSTYPE PORTS   ENDPOINTS            AGE
my-endpointslice IPv4      80/TCP  10.2xx.0.1,10.2xx.0.2 12h
    7. Verify the Kubernetes resources were created properly:
      a. Check the service accounts

kubectl get serviceaccounts -n kube-system | grep pan

b. Check the secrets

kubectl get secrets -n kube-system | grep pan

c. Check the services:

`kubectl get svc -n kube-system | grep pan`
      You should see resources like pan-cni-sa (service accounts), pan-plugin-user-secret (secrets), and pan-ngfw-svc (service).
    8. Annotate at the pod level in your application yaml so that the traffic from the pod is redirected to the Prisma AIRS AI Runtime: Network intercept for inspection.
      Annotate the pod using the below command:
      • For VPC-level security:
        kubectl annotate namespace <namespace-to-be-annotated> paloaltonetworks.com/firewall=pan-fw
      • For namespace-level security with traffic steering inspection:
        kubectl annotate pods --all paloaltonetworks.com/subnetfirewall=ns-secure/bypassfirewall
      Ensure every pod has this annotation to be moved to the ‘protected’ state across all cloud environments.
      Restart the existing application pods after applying Helm and annotating the pods for all changes to take effect. This enables the firewall to inspect the pod traffic and secure the containers.

    Azure

    Prisma AIRS AI Runtime: Network intercept post-deployment configurations in Strata Cloud Manager and Azure to protect VM workloads and Kubernetes clusters.
    Where Can I Use This?What Do I Need?
    • Secure VMs and Kubernetes Clusters in Azure

    Configure Strata Cloud Manager

    Interfaces

    1. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Interfaces.
    2. Set the Configuration Scope to your AI Runtime Security folder.
    3. Select Add Interface.
      • In the Ethernet tab, configure a Layer 3 Interface for eth1/1(trust) and eth1/2(untrust):
        • Enter Interface Name (Create interfaces for both eth1/1(trust) and eth1/2(untrust) interfaces).
        • Select Layer3 Interface type.
        • In Logical Routers, select `vr-private` for eth1/1 and `vr-public` for eth1/2.
        • In Zone, select trust for eth1/1 and untrust for eth1/2.
        • Select DHCP Client type under IPV4 address.
        • Enable IPV4 for both eth1/1 and eth1/2 interfaces.
        • For eth1/2 (untrust) only, enable Automatically create default route pointing to default gateway provided by server.
        • Select Advanced Settings > Other Info.
        • Select a Management Profile or create a new one.
          In Administrative Management Services, enable HTTPS.
        • Click Add.
      • Select the Loopback tab to configure the Loopback interface to receive health checks from each load balancer:
        • Select the Logical Routers.
        • Set the trust Zone for private Logical Router and untrust Zone for the public Logical Router.
        • In the IPv4s section, enter the private IP address of the Internal Load Balancer (ILB).
          This IP address is in the output displayed after successfully deploying the `security_project` Terraform, as described in the Deploy AI Runtime Security: Network Intercept in Azure page.
        • Expand Advanced Settings → Management Profile and add your allow-health-checks profile.
        • Add or Save.

    Zones

    1. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Zones.
    2. Select Add Zone.
    3. Enter a Name.
    4. Select Layer3 Interface type.
    5. In Interfaces, add $eth1 interface for the trust zone and $eth2 interface for the untrust zone.
    6. Save.

    NAT

    Configure the NAT policies for inbound and outbound traffic:
    1. Navigate to Manage→ Configuration → NGFW and Prisma Access → Network Policies → NAT.
    2. Configure NAT Policy for inbound traffic:
      1. Enter a Name indicating inbound traffic (for example, inbound-web).
      2. Original Packet:
        • In Source zones, click add and select the untrust zone.
      3. Destination:
        • Select trust Zone.
        • Select any Interface.
        • In Addresses, click the add (+) icon and select the public Elastic Load Balancer (ELB) address.
      4. Choose any Service.
      5. Translated Packet:
        • In Translation, select Both.
        • In Source Address Translation, select the Dynamic IP and Port translation type.
        • In the choice, select Interface Address.
        • In Interface, select eth1(ethernet1/1).
        • In the Choice, select IP address.
        • Set the Static IP address as the Translation Type.
        • Select the destination Translated Address.
      6. Save.
    3. Configure NAT Policy for Outbound traffic:
      1. Enter a Name indicating outbound traffic (for example, outbound-internet).
      2. Original Packet:
        • In Source zones, click add and select trust zone.
        • In Addresses, click the add (+) icon and select the app-vnet and the Kubernetes pods CIDR you want to secure.
      3. Destination:
        • Select the untrust destination zone.
        • Select any interface.
      4. Choose any Service.
      5. Translated Packet:
        • In Translation, select Source Address Only.
        • In Source Address Translation, select the Dynamic IP and Port translation type.
        • In choice, select Interface Address.
        • In Interface, select eth2(ethernet1/2).
        • In Choice, select IP address.
      6. Save.

    Routers

    Configure private and public virtual routers:
    Azure health probe fails with a single virtual router (VR). Create multiple VRs to ensure probe success.
    1. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Routing.
    2. Enter a Name indicating private and public routers (for example, vr-private and vr-public).
    3. In Interfaces, select eth1(ethernet1/1) for the vr-private route and eth2(ethernet1/2)for the vr-public route.
      Refer to the above section on Interfaces to see how to configure the $eth1 and $eth2 interfaces.
    4. In Advanced Settings, select Edit to configure the IPV4 Static Routes for vr-private and vr-public.
      1. Select Add Static Route and add the following routes:
      2. Application routing:
        1. Enter a Name for example, app-vnet.
        2. In Destination, enter the CIDR address of your application.
        3. In Next Hop:
          • For vr-private, in the IP Address field, enter the gateway IP address of the private interface (eth1/1).
            The gateway IP address is the first usable IP in the subnet's range (example, 192.168.1.1 for a /24 subnet). To find it, go to Azure Portal > Virtual Networks > [Your Virtual Network] > Subnets > [Private Subnet].
          • For vr-public, in the Next Router field, enter `vr-public`.
        4. In Interface, select eth1(ethernet1/1) subnet for `vr-private` and None for `vr-public`.
      3. Default routing:
        1. Enter a Name.
        2. In Destination, enter 0.0.0.0/0.
        3. In Next Hop:
          • For vr-private, in the Next Router field, enter the `vr-private`.
          • For vr-public, select IP Address . In the IP Address field, enter the gateway IP address of the vr-public interface (eth1/2).
        4. In Interface, choose None for `vr-private` and eth2(ethernet1/2) for `vr-public`.
        5. Click Add or Update.
      4. Azure Load Balancer’s health probe:
        1. Enter a Name.
        2. In Destination, enter the IP address of the Azure Load Balancer’s health probe (168.63.129.16/32).
        3. In Next Hop, select IP Address for vr-private and vr-public.
          • In IP Address, enter the gateway IP address of the corresponding interface.
        4. In Interface, select eth1(ethernet1/1) for vr-private and eth2(ethernet1/2) for vr-public.
      5. Click Add.
    5. Click Save.

    Security Policy

    1. Log in to Strata Cloud Manager.
    2. Add a security policy (Manage→ Configuration → NGFW and Prisma Access → Security Services → Security Policy → Add Rule).
    3. Set the action to Allow.
      Ensure the policy allows health checks from the Azure Load Balancer (LB) pool to the internal LB IP from Strata Cloud Manager. Check session IDs to ensure the firewall responds correctly on the designated interfaces.

    Configurations to Secure VM Workloads

    1. Log in to Strata Cloud Manager.
      Configure routes for vNet endpoints as explained in the Routers section above to ensure a route to your application.
    2. Navigate to Configuration → Push Config and push the policy configurations to your Prisma AIRS AI Runtime: Network intercept.
    3. Create or update the NAT policy (refer to the NAT section above) to secure the VM workloads. Set the source address of the application you want to secure.

    Configurations to Secure Kubernetes Clusters

    1. Log in to Strata Cloud Manager.
    2. Configure static routes (refer to the routes section above) on the Logical Router for Kubernetes workloads.
    3. Below are the configurations for pod and service subnets static routes for the Kubernetes workloads:
      1. Pod Subnet and Service subnet for vr-private:
        Route TypeNameDestinationNext HopNext Hop ValueInterface
        Pod subnetpod_routePod IPV4 range CIDRIP AddressSubnet Gateway IP addresseth1(ethernet1/1)
        Service subnetservice_route172.16.0.0/24IP AddressSubnet Gateway IP addresseth1(ethernet1/1)
      2. Pod Subnet and Service subnet for vr-public:
        Route TypeNameDestinationNext HopNext Hop ValueInterface
        Pod subnetpod_routePod IPV4 range CIDRNext Routervr-publicNone
        Service subnetservice_route172.16.0.0/24Next Routervr-publicNone
    4. Refer to the NAT policy in the above section to secure the Kubernetes clusters and set the source address of the Kubernetes pods CIDR you want to secure.
    5. Navigate to Configuration → Push Config and push the policy configurations to Prisma AIRS AI Runtime: Network intercept.

    Secure a Kubernetes Application with Helm

    This section covers how to install and configure the Helm chart to secure your Kubernetes applications based on the protection level you selected during deployment.
    The Helm chart installation process and directory structure vary depending on whether you selected VPC-level protection or namespace-level protection with traffic steering inspection. VPC-level protection secures all applications within the VPC, while namespace-level protection with traffic inspection provides granular control over specific application traffic flows and CIDR-based inspection rules.
    Your deployment configuration determines the specific Helm chart structure and commands required for your environment.
    .
    1. Navigate to the downloaded tar file and extract the contents:
      tar -xvzf <your-terraform-download.tar.gz>
    2. Navigate to the appropriate Helm directory based on your deployment configuration:
      • For VPC-level security:
        cd <unzipped-folder>/architecture/helm
      • For namespace-level security with traffic steering inspection:
        cd <unzipped-folder>/architecture/helm-<complete-app-name-path>
        Navigate to each Helm application folder. When you configure traffic steering inspection, separate Helm charts are generated for each protected namespace, allowing granular security policies per application.
    3. Install the Helm chart using the appropriate command:
      • For VPC-level security:
        helm install ai-runtime-security helm --namespace kube-system --values helm/values.yaml
      • For namespace-level security with traffic steering inspection:
        helm install ai-runtime-security helm-<complete-app-name-path> --namespace kube-system --values helm-<complete-app-name-path>/values.yaml
        Repeat this command for each namespace-specific Helm chart generated during the deployment process.
      Enable "Bring your own Azure virtual network" to discover Kubernetes-related vnets:
      1. In Azure Portal, navigate to Kubernetes services → [Your Cluster]→ Settings→ Networking.
      2. Under Network configuration, select Azure CNI as the Network plugin, then enable Bring your own Azure virtual network.
      This creates a container network interface (CNI), but doesn’t protect the container traffic until you annotate the application `yaml` or `namespace`.
    4. Verify the Helm installation: 
      #List all Helm releases
helm list -A

#Ensure the output shows your installation with details such as:
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
    5. Check the pod status: 
      kubectl get pods -A
#Verify that the pods with names similar to `pan-cni-*****` are present.
    6. Check the endpoint slices: 
      kubectl get endpointslice -n kube-system

#Confirm that the output shows an ILB IP address:
NAME             ADDRESSTYPE PORTS   ENDPOINTS            AGE
my-endpointslice IPv4      80/TCP  10.2xx.0.1,10.2xx.0.2 12h
    7. Verify the Kubernetes resources were created properly:
      a. Check the service accounts

kubectl get serviceaccounts -n kube-system | grep pan

b. Check the secrets

kubectl get secrets -n kube-system | grep pan

c. Check the services:

`kubectl get svc -n kube-system | grep pan`
      You should see resources like pan-cni-sa (service accounts), pan-plugin-user-secret (secrets), and pan-ngfw-svc (service).
    8. Annotate at the pod level in your application yaml so that the traffic from the pod is redirected to the Prisma AIRS AI Runtime: Network intercept for inspection.
      Annotate the pod using the below command:
      • For VPC-level security:
        kubectl annotate namespace <namespace-to-be-annotated> paloaltonetworks.com/firewall=pan-fw
      • For namespace-level security with traffic steering inspection:
        kubectl annotate pods --all paloaltonetworks.com/subnetfirewall=ns-secure/bypassfirewall
      Ensure every pod has this annotation to be moved to the ‘protected’ state across all cloud environments.
      Restart the existing application pods after applying Helm and annotating the pods for all changes to take effect. This enables the firewall to inspect the pod traffic and secure the containers.

    AWS

    Prisma AIRS AI Runtime: Network intercept post-deployment configurations in Strata Cloud Manager and AWS to protect VM workloads and Kubernetes clusters.
    Where Can I Use This?What Do I Need?
    • Secure VMs and Kubernetes Clusters in AWS

    Interfaces

    To configure a firewall with overlay routing enabled, you must use two interfaces:
    trust-interface (ethernet1/1) and untrust-interface (ethernet1/2). If overlay routing is not enabled, then configure the firewall with only one interface, the trust-interface.
    1. Log in to Strata Cloud Manager.
    2. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Interfaces.
    3. Set the Configuration Scope to your Prisma AIRS AI Runtime: Network intercept folder.
    4. Select Add Interface.
    5. In Ethernet tab:
      1. Enter an Interface Name.
      2. Select the Default Interface Assignment from the available list.
      3. In Interface Type, select Layer 3.
      4. When configuring the Ethernet tab, you can either:
        • Associate an existing Logical Router and Zone from the available lists.
        • Leave the selections empty and associate them later when the logical router and zone are created.
        Assign the trust-zone to the trust interface and the untrust-zone to the untrust interface.
      5. In IPv4, select Dynamic (DHCP Client).
      For overlay routing, uncheck the box for "Automatically create default route pointing to default gateway provided by server" on the ethernet1/1 (trust) interface.
    6. Select Save.

    Zones

    1. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Zones.
    2. Select Add Zone.
    3. Enter a Name.
    4. Select Layer3 Interface type.
    5. In Interfaces, add ethernet1/1 interface for the trust-zone and ethernet1/2 for the untrust-zone.
    6. Select Save.

    Routers

    Configure `trust-logical-router` and `untrust-logical-router`:
    1. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Routing.
    2. Enter the routing Name. Use trust-logical-router for ethernet1/1 and untrust-logical-router for ethernet1/2.
    3. In Interfaces, select $trust-interface or $untrust-interface for trust-logical-router and untrust-logical-router logical routers, respectively.
    4. In Advanced Settings, select Edit to configure the IPV4 Static Routes fortrust-logical-router and untrust-logical-router.
    5. Select Add Static Route and add 4 static routes for `trust-logical-router` and 3 for `untrust-logical-router`.
      The following are the configurations for each logical router:
      trust-logical-router
      NameDestinationInterfaceNext Hop
      10.x-route10.0.0.0/8$eth1IP Address
      172.16.x-route172.16.0.0/12$eth1IP Address
      192.168.x-route192.168.0.0/16$eth1IP Address
      default0.0.0.0/0NoneNext Logical Router: untrust-lr
      The IP Address is the gateway IP address for the ethernet1/1 subnet.
      The Next Logical Router is the `untrust` logical router for ethernet1/1.
      untrust-logical-router
      NameDestinationInterfaceNext Hop
      10.x-route10.0.0.0/8NoneNext Logical Router: trust-lr
      172.16.x-route172.16.0.0/12NoneNext Logical Router: trust-lr
      192.168.x-route192.168.0.0/16NoneNext Logical Router: trust-lr
      The Next Logical Router is the trust logical router `trust-lr`.
    6. Select Save.

    NAT

    Add a NAT policy for outbound traffic if you have enabled overlay routing on the firewall.
    1. Navigate to Manage→ Configuration → NGFW and Prisma Access → Network Policies → NAT.
    2. Enter a Name (trust-to-untrust-zone-nat).
    3. Original Packet:
      1. In Source zones, click add and select the trust zone.
    4. Destination:
      1. In Zone, select untrust-zone.
      2. In Interface, select untrust-interface (ethernet1/2).
    5. Choose any Service.
    6. Translated Packet:
      1. In Translation, select Source Address Only.
      2. In Source Address Translation, select the Dynamic IP and Port translation type.
      3. In Choice, select Interface Address.
      4. In Interface, select `$untrust-interface (ethernet1/2)`.
      5. In Choice, select the IP address.
    7. Select Save.

    Security Policy

    Create a security policy with an allow rule and associate it with a security policy profile group to permit necessary traffic.
    1. Log in to Strata Cloud Manager.
    2. Navigate to Manage→ Configuration → NGFW and Prisma Access → Security Services → Security Policy.
    3. Select Add Rule.
    4. Set the action to Allow.
    5. Select Configuration Push Config and push the policy configurations to the Prisma AIRS AI Runtime: Network intercept.

    Secure a Kubernetes Application with Helm

    This section covers how to install and configure the Helm chart to secure your Kubernetes applications based on the protection level you selected during deployment.
    The Helm chart installation process and directory structure vary depending on whether you selected VPC-level protection or namespace-level protection with traffic steering inspection. VPC-level protection secures all applications within the VPC, while namespace-level protection with traffic inspection provides granular control over specific application traffic flows and CIDR-based inspection rules.
    Your deployment configuration determines the specific Helm chart structure and commands required for your environment:
    • Go to your downloaded Terraform template, unzip it, and navigate to `<unzipped-folder>/architecture/helm`.
    • Apply Terraform for the application_project as shown in the AWS deployment workflow.
      Deploying Terraform for the application_project creates the GWLB endpoints in your AWS account.
      To view and copy the GWLB endpoints1 and endpoints2 IP addresses, log in to the Amazon Management Console. Go to VPC > Endpoints and under the Subnets tab, copy the IP addresses for your region.
    • Open the `values.yaml` file in the path: `<unzipped-folder>/architecture/helm`.
    • Update the `endpoints1` and `endpoints2` values with your GWLB endpoints' IP addresses. Below is a sample `values.yaml` file:
      # Default values for ai-runtime-security.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

# Configure vpc endpoint per zone. This makes sure kubernetes
# traffic is not sent across zone. Endpoints can be added or
# removed based on requirements and zone availability.
# GWLB VPC endpoint zone1 IP address.
endpoints1: ""
endpoints1zone: us-east-1a

# GWLB VPC endpoint zone2 IP address.
endpoints2: ""
endpoints2zone: us-east-1b

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

# Resource namespace name.
namespace: kube-system

# Kubernetes ClusterID value range 1-2048.
clusterid: 1
    • Apply the helm chart by following the steps below:
    1. Navigate to the downloaded tar file and extract the contents:
      tar -xvzf <your-terraform-download.tar.gz>
    2. Navigate to the appropriate Helm directory based on your deployment configuration:
      • For VPC-level security:
        cd <unzipped-folder>/architecture/helm
      • For namespace-level security with traffic steering inspection:
        cd <unzipped-folder>/architecture/helm-<complete-app-name-path>
        Navigate to each Helm application folder. When you configure traffic steering inspection, separate Helm charts are generated for each protected namespace, allowing granular security policies per application.
      Repeat the above prerequisites, update the `values.yaml` file with the GWLB endpoints for each VPC/namespace you entered while creating the AWS deployment terraform, and apply the helm chart.
    3. Install the Helm chart using the appropriate command:
      • For VPC-level security:
        helm install ai-runtime-security helm --namespace kube-system --values helm/values.yaml
      • For namespace-level security with traffic steering inspection:
        helm install ai-runtime-security helm-<complete-app-name-path> --namespace kube-system --values helm-<complete-app-name-path>/values.yaml
        Repeat this command for each namespace-specific Helm chart generated during the deployment process.
      This creates a container network interface (CNI), but doesn’t protect the container traffic until you annotate the application `yaml` or `namespace`.
    4. Verify the Helm installation: 
      #List all Helm releases
helm list -A

#Ensure the output shows your installation with details such as:
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
    5. Check the pod status: 
      kubectl get pods -A
#Verify that the pods with names similar to `pan-cni-*****` are present.
    6. Check the endpoint slices: 
      kubectl get endpointslice -n kube-system

#Confirm that the output shows an ILB IP address:
NAME             ADDRESSTYPE PORTS   ENDPOINTS            AGE
my-endpointslice IPv4      80/TCP  10.2xx.0.1,10.2xx.0.2 12h
    7. Verify the Kubernetes resources were created properly:
      a. Check the service accounts

kubectl get serviceaccounts -n kube-system | grep pan

b. Check the secrets

kubectl get secrets -n kube-system | grep pan

c. Check the services:

`kubectl get svc -n kube-system | grep pan`
      You should see resources like pan-cni-sa (service accounts), pan-plugin-user-secret (secrets), and pan-ngfw-svc (service).
    8. Annotate at the pod level in your application yaml so that the traffic from the pod is redirected to the Prisma AIRS AI Runtime: Network intercept for inspection.
      Annotate the pod using the below command:
      • For VPC-level security:
        kubectl annotate namespace <namespace-to-be-annotated> paloaltonetworks.com/firewall=pan-fw
      • For namespace-level security with traffic steering inspection:
        kubectl annotate pods --all paloaltonetworks.com/subnetfirewall=ns-secure/bypassfirewall
      Ensure every pod has this annotation to be moved to the ‘protected’ state across all cloud environments.
      Restart the existing application pods after applying Helm and annotating the pods for all changes to take effect. This enables the firewall to inspect the pod traffic and secure the containers.

    © 2025 Palo Alto Networks, Inc. All rights reserved.