AI Runtime Security
Azure
Table of Contents
Expand All
|
Collapse All
AI Runtime Security Docs
-
- AI Models on Public Clouds Support
-
- Deploy AI Runtime Security: Network Intercept in GCP
- Deploy AI Runtime Security: Network Intercept in Azure
- Deploy AI Runtime Security: Network Intercept in AWS
- Configure Strata Cloud Manager to Secure VM Workloads and Kubernetes Clusters
- Harvest IP-Tags from Public and Hybrid Kubernetes Clusters to Enforce Security Policy Rules
- AI Runtime Security for Private Clouds
- Manually Deploy and Bootstrap AI Runtime Security: Network Intercept
Azure
AI Runtime Security 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? |
---|---|
|
Configure Strata Cloud Manager
Interfaces
Configure AI Runtime Security (firewall) Interfaces:
- Navigate to Manage → Configuration → NGFW and Prisma Access→ Device Settings → Interfaces
- Set the Configuration Scope to your AI Runtime Security folder.
- 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 Layer3Interface 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 switch HTTPS enabled under Administrative Management Services or create a new one:
- 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.
Expand allCollapse all
Zones
- Navigate to Manage → Configuration → NGFW and Prisma Access→ Device Settings → Zones.
- Select Add Zone.
- Enter a Name.
- Select Layer3 Interface type.
- In Interfaces, add $eth1 interface for trust zone and $eth2 interface for untrust zone.
- Save.
NAT
- Navigate to Manage → Configuration → NGFW and Prisma Access → Network Policies → NAT.
- Configure NAT Policy for inbound traffic:
- Enter a Name indicating inbound traffic (for example, inbound-web).
- Original Packet:
- In Source zones, click add and select untrust zone.
- Destination:
- select untrust Zone.
- Select any Interface.
- In Addresses, click the add (+) icon and select the public Elastic Load Balancer (ELB) address.
- Choose any Service.
- Translated Packet:
- In Translation, select Both.
- In Source Address Translation, select the Dynamic IP and Port translation type.
- In choice, select Interface Address.
- In Interface, select eth1(ethernet1/1).
- In Choice, select IP address.
- Set the Static IP address as the Translation Type.
- Select the destination Translated Address.
- Save.
- Configure NAT Policy for Outbound traffic:
- Enter a Name indicating inbound traffic (for example, outbound-internet).
- 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.
- Destination:
- Select untrust destination zone.
- Select any interface.
- Choose any Service.
- 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.
- Save.
Routers
Azure health probe fails with a single virtual router
(VR). Create multiple VRs to ensure probe success.
- Navigate to Manage → Configuration → NGFW and Prisma Access→ Device Settings → Routing.
- Enter a Name indicating private and public routers (for example, vr-private and vr-public).
- In Interfaces, select eth1(ethernet1/1) for vr-private route and eth2(ethernet1/2) for vr-public route.Refer the section on Interfaces to see how to configure the $eth1 and $eth2 interfaces.
- In Advanced Settings, select Edit to configure the IPV4 Static Routes for vr-private and vr-public.
- Select Add Static Route and add the following routes:
- Application routing:
- Enter a Name (for example, app-vnet).
- In Destination, enter the CIDR address of your application.
- In Next Hop:
- For vr-private, select IP Address
and enter the gateway IP address of the private
interface (eth1/1) in the IP Address.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, select Next Router and select the `vr-private` in the Next Router.
- For vr-private, select IP Address
and enter the gateway IP address of the private
interface (eth1/1) in the IP Address.
- In Interface, select eth1(ethernet1/1) subnet for `vr-private` and None for `vr-public`.
- Default routing:
- Enter a Name.
- In Destination, enter 0.0.0.0/0.
- In Next Hop:
- For vr-private, select Next Router and enter the `vr-public` in the Next Router.
- For vr-public, select IP Address and enter the gateway IP address of the vr-public interface (eth1/2) in the IP Address.
- In Interface, choose None for `vr-private` and eth2(ethernet1/2) for `vr-public`.
- Add or Update.
- Azure Load Balancer’s health probe:
- Enter a Name.
- In Destination, enter the IP address of the Azure Load Balancer’s health probe (168.63.129.16/32).
- In Next Hop, select IP Address for
vr-private and vr-public.
- In IP Address, enter the gateway IP address of the corresponding interfaces.
- In Interface, select eth1(ethernet1/1) for vr-private and eth2(ethernet1/2) for vr-public.
- Add.
- Save.
- Static routes summary for `vr-private`:
Route Type Name Destination Next Hop Next Hop Value Interface Application routing app-vnet Application CIDR IP Adderss Gateway IP address of vr-private Gateway IP address of vr-private Default Routing default 0.0.0.0/0 Next Router vr-public None Azure LB Health Probe azure-probe 168.63.129.16/32 IP Address Subnet Gateway IP address eth1(ethernet1/1) - Static route summary for `vr-public`:
Route Type Name Destination Next Hop Next Hop Value Interface Application routing app-vnet Application CIDR Next Router vr-private eth1(ethernet1/1) Default Routing default 0.0.0.0/0 IP Address Gateway IP address of vr-public eth2(ethernet1/2) Azure LB Health Probe azure-probe 168.63.129.16/32 IP Address Subnet Gateway IP address eth2(ethernet1/2)
Security Policy
- Add a security policy (Manage → Configuration → NGFW and Prisma Access → Security Services → Security Policy → Add Rule). 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
- Log in to Strata Cloud Manager.Configure routes for vNet endpoints as explained in the Routers section above to ensure there is a route to your application.
- Navigate to Manage → Operations → Push Config and push the policy configurations to your AI network intercept (AI firewall).
- 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 the Kubernetes Clusters
- Log in to Strata Cloud Manager.
- Configure static routes (refer to the routes section above) on the Logical Router for Kubernetes workloads.
- Follow the below configurations for pod and service subnets static routes for pod for the Kubernetes workloads:
- Pod Subnet and Service subnet for vr-private:
Route Type Name Destination Next Hop Next Hop Value Interface Pod subnet pod_route Pod IPV4 range CIDR IP Address Subnet Gateway IP address eth1(ethernet1/1) Service subnet service_route 172.16.0.0/24 IP Address Subnet Gateway IP address eth1(ethernet1/1) - Pod Subnet and Service subnet for vr-public:
Route Type Name Destination Next Hop Next Hop Value Interface Pod subnet pod_route Pod IPV4 range CIDR Next Router vr-private None Service subnet service_route 172.16.0.0/24 Next Router vr-private None
- Pod Subnet and Service subnet for vr-private:
- 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.
- Navigate to Manage → Operations → Push Config and push the policy configurations to your firewall (AI Runtime Security: Network intercept).
Install a Kubernetes Application with Helm
- Change the directory to the Helm folder:cd <unzipped-folder>/architecture/helm
- Install the Helm chart:helm install ai-runtime-security helm --namespace kube-system --values helm/values.yamlEnable "Bring your own Azure virtual network" to discover Kubernetes-related vnets:
- In Azure Portal, navigate to Kubernetes services → [Your Cluster]→ Settings→ Networking.
- 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`. Restart the existing application pods within the CNI after the `helm` application. - 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
- Check the pod status:kubectl get pods -A #Verify that the pods with names similar to `pan-cni-*****` are present.
- 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
- Check the services running in the `kube-system` namespace:kubectl get svc -n kube-system #Ensure that services `pan-cni-sa` and `pan-plugin-user-secret` are listed: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE pan-cni-sa ClusterIP 10.xx.0.1 <none> 443/TCP 24h pan-plugin-user-secret ClusterIP 10.xx.0.2 <none> 443/TCP 24h
- Annotate the application `yaml` or `namespace` so that the traffic from the new pods is redirected to the AI Runtime Security: Network intercept (AI firewall) for inspection.
For example, for all new pods in the "default" namespace:annotations: paloaltonetworks.com/firewall: pan-fwkubectl annotate namespace default paloaltonetworks.com/firewall=pan-fwAny pod deployed with the helm chart in an annotated namespace will be secured and monitored.