AWS
Focus
Focus
Prisma AIRS

AWS

Table of Contents


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. Navigate to Manage→ Configuration → NGFW and Prisma Access→ Device Settings → Interfaces.
  2. Set the Configuration Scope to your Prisma AIRS AI Runtime: Network intercept folder.
  3. Select Add Interface.
  4. 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.
  5. 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. Navigate to Manage→ Configuration → NGFW and Prisma Access → Security Services → Security Policy.
  2. Select Add Rule.
  3. Set the action to Allow.
  4. 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.