Deploy the CN-Series Firewall as a Kubernetes Service on AWS EKS

Set up your Kubernetes cluster.
To create a cluster in AWS EKS, do the following:
Click the

Services

navigation menu, go to

Containers

->

Elastic Kubernetes Service

.



Click

Create Cluster

.

Fill in the required details, and then click

Create

.


Verify that the cluster has adequate resources. Make sure that cluster has the CN-Series Prerequisites resources to support the firewall:
kubectl get nodes
kubectl describe node <node-name>
View the information under the Capacity heading in the command output to see the CPU and memory available on the specified node.
Resource	CN-MGMT Small	CN-NGFW Small	CN-MGMT Medium	CN-NGFW Medium	CN-MGMT Large	CN-NGW Large
Memory (Min)	2Gi	2.5Gi	2Gi	6Gi	4Gi	48Gi
CPU (Recommended Min)	2	2	2	4	4	12
CPU (Max)	None	31	None	31	None	31
Disk	50GiB	N.A.	50GiB	N.A.	50GiB	N.A.
The CPU, memory and disk storage allocation will depend on your needs. See CN-Series Performance and Scaling.
Ensure you have the following information:
Collect the Endpoint IP address for setting up the API server on Panorama.

Panorama uses this IP address to connect to your Kubernetes cluster.
Collect the template stack name, device group name, Panorama IP address, and optionally the Log Collector Group Name from Panorama.

For more information, see Create a parent Device Group and Template Stack.
Collect the VM Auth Key and auto-registration PIN ID and value.
Collect the full path of the container image repository to which you have downloaded the docker images.
(
optional
) If you configured a custom certificate in the Kubernetes plugin for Panorama, you must create the cert secret by executing the following command. Do not change the file name from ca.crt. The volume for custom certificates in pan-cn-mgmt.yaml and pan-cn-ngfw.yaml is optional.
kubectl -n kube-system create secret generic custom-ca --from-file=ca.crt
Edit the YAML files to provide the details required to deploy the CN-Series firewalls.
You need to replace the image path in the YAML files to include the path to your private registry and provide the required parameters. See Editable Parameters in CN-Series Deployment YAML Files and Get the Images and Files for the CN-Series Deployment.
Update the storage class. To support the CN-Series deployed on AWS Outpost, you must use the storage driver aws-ebs-csi-driver, which ensures that Outpost pulls the volumes from the Outpost during dynamic Persistent Volume (PV) creation.
Apply the following yaml.

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-0.10"

Verify that the ebs-sc controller is running.

kubectl -n kube-system get pods

Update pan-cn-storage-class.yaml to match the example below.

apiVersion: v1
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp2

Add

storageClassName: ebs-sc

to pan-cn-mgmt.yaml in the locations shown below.

volumeClaimTemplates:
  - metadata:
      name: panlogs
    spec:
      #storageClassName: pan-cn-storage-class //For better disk iops performance for logging
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc     //
      resources:
        requests:
          storage: 20Gi # change this to 200Gi while using storageClassName for better disk iops
  - metadata:
      name: varlogpan
    spec:
      #storageClassName: pan-cn-storage-class //For better disk iops performance for dp logs
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc
      resources:
        requests:
          storage: 20Gi # change this to 200Gi while using storageClassName for better disk iops
  - metadata:
      name: varcores
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc
      resources:
        requests:
          storage: 2Gi
  - metadata:
      name: panplugincfg
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc
      resources:
        requests:
          storage: 1Gi
  - metadata:
      name: panconfig
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc
      resources:
        requests:
          storage: 8Gi
  - metadata:
      name: panplugins
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: ebs-sc
      resources:
        requests:
          storage: 200Mi
If you are using autoscaling in your Kubernetes environment, do the following:
Deploy the Amazon CloudWatch Metrics Adapter for Kubernetes in your CN-Series as a Service cluster. You must allow CloudWatch complete access to both IAM roles associated with your Kubernetes pods and clusters. To publish the custom metrics to CloudWatch, the worker nodes’ role must have the AWS managed policy
CloudWatchAgentServerPolicy
so that the HPA can retrieve them.
Download the EKS-specific HPA yaml files from the Palo Alto Networks GitHub repository.
If your CN-MGMT is deployed in a custom namespace, update pan-cn-adapater.yaml with the custom namespace. The default namespace is
kube-system
.
Modify
pan-cn-hpa-dp.yaml
and
pan-cn-hpa-mp.yaml
.
Enter the minimum and maximum number of replicas.
(
Optional
) Change the scale down and scale up frequency values to suit your deployment. If you do not change these values, the default values are used.
Copy the following section for each metric you want to use for scaling.
- type: Pods
    pods:
      metric:
       name: pansessionactive
      target:
        type: AverageValue
averageValue: 30
Change the name of the metric you want to use and set the
averageValue
to the threshold described in the table above. If you do not change these values, the default values are used.
Save your changes.
For more information, see Horizontal Pod Autoscaling.
Deploy the HPA yaml files. The files must be deployed in the order described below.
Use Kubectl to run the pan-cn-adapter.yaml
kubectl apply -f pan-cn-adapter.yaml
Use Kubectl to run the pan-cn-externalmetrics.yaml
kubectl apply -f pan-cn-externalmetrics.yaml
Use Kubectl to run the pan-cn-hpa-dp.yaml
kubectl apply -f pan-cn-hpa-dp.yaml
Use Kubectl to run the pan-cn-hpa-mp.yaml
kubectl apply -f pan-cn-hpa-mp.yaml
Verify your deployment.
Use kubectl to verify that the custom metrics adapter pod is in the custom metrics namespace.
kubectl get pods -n custom-metrics
Use kubectl to check for the HPA resource.
kubectl get hpa -n kube-system
kubectl describe hpa <hpa-name> -n kube-system
Deploy the CN-NGFW service.
Verify that you have created the service account using the pan-cni-serviceaccount.yaml.

See Create Service Account for Cluster Authentication.

Use Kubectl to run the pan-cni-configmap.yaml.

kubectl apply -f pan-cni-configmap.yaml

Use kubectl to run the pan-cn-ngfw-svc.yaml.

kubectl apply -f pan-cn-ngfw-svc.yaml

This yaml must be deployed before pan-cni.yaml.

Use Kubectl to run the pan-cni.yaml.

kubectl apply -f pan-cni.yaml

Verify that you have modified the pan-cni-configmap and pan-cni YAML files.

Run the following command and verify that your output is similar to the following example.

kubectl get pods -n kube-system | grep pan-cni


Deploy the CN-MGMT StatefulSet.
By default, the management plane is deployed as a StatefulSet that provides fault tolerance. Up to 30 firewall CN-NGFW pods can connect to a CN-MGMT StatefulSet.
(

Required for statically provisioned PVs only

) Deploy the Persistent Volumes (PVs) for the CN-MGMT StatefulSet.

Create the directories to match the local volume names defined in the pan-cn-pv-local.yaml.
You need six (6) directories on at least 2 worker nodes. Log in to each worker node on which the CN-MGMT StatefulSet will be deployed to create the directories. For example, to create directories named /mnt/pan-local1 to /mnt/pan-local6, use the command:
mkdir -p /mnt/pan-local1 /mnt/pan-local2 /mnt/pan-local3 /mnt/pan-local4 /mnt/pan-local5 /mnt/pan-local6
Modify pan-cn-pv-local.yaml.
Match the hostname under
nodeaffinity
, and verify that you have modified the directories you created above in
spec.local.path
then deploy the file to create a new storageclass pan-local-storage and local PVs.

Verify that you have modified the pan-cn-mgmt-configmap and pan-cn-mgmt YAML files.

Sample pan-cn-mgmt-configmap from EKS.

	apiVersion: v1
kind: ConfigMap
metadata:
  name: pan-mgmt-config
  namespace: kube-system
data:
  PAN_SERVICE_NAME: pan-mgmt-svc
  PAN_MGMT_SECRET: pan-mgmt-secret
  # Panorama settings
  PAN_PANORAMA_IP: "<panorama-IP>"
  PAN_DEVICE_GROUP: "<panorama-device-group>"
  PAN_TEMPLATE_STACK: "<panorama-template-stack>"
  PAN_CGNAME: "<panorama-collector-group>"
  # ctnr mode: "k8s-service", "k8s-ilbservice"
  PAN_CTNR_MODE_TYPE: "k8s-service"
#Non-mandatory parameters
  # Recommended to have same name as the cluster name provided in Panorama Kubernetes plugin - helps with easier identification of pods if managing multiple clusters with same Panorama
  #CLUSTER_NAME: "<Cluster name>"
  #PAN_PANORAMA_IP2: ""
  # Comment out to use CERTs otherwise PSK for IPSec between pan-mgmt and pan-ngfw
  #IPSEC_CERT_BYPASS: ""         # No values needed
  # Override auto-detect of jumbo-frame mode and force enable system-wide
  #PAN_JUMBO_FRAME_ENABLED: "true"
  # Start MGMT pod with GTP enabled. For complete functionality, need GTP 
  # enable at Panorama as well.
  #PAN_GTP_ENABLED: "true"
  # Enable high feature capacities. These need high memory for MGMT pod and
  # higher/matching memory than specified below for NGFW pod.
  #PAN_NGFW_MEMORY="6Gi"
  #PAN_NGFW_MEMORY="40Gi"
  # For enabling faster datapath - AF_XDP, default is AF_PACKETV2. This requires kernel support.
  #PAN_DATA_MODE: "next-gen"
  #HPA params
  #PAN_CLOUD: "EKS"
  #PAN_NAMESPACE_EKS: "EKSNamespace"
  #PUSH_INTERVAL: "15" #time interval to publish metrics to AWS cloudwatch

Sample pan-cn-mgmt.yaml

initContainers:        - name: pan-mgmt-init          image: <your-private-registry-image-path>     

 containers:        - name: pan-mgmt          image: <your-private-registry-image-path>          terminationMessagePolicy: FallbackToLogsOnError

Use Kubectl to run the yaml files.

kubectl apply -f pan-cn-mgmt-configmap.yaml

kubectl apply -f pan-cn-mgmt-slot-crd.yaml

kubectl apply -f pan-cn-mgmt-slot-cr.yaml

kubectl apply -f pan-cn-mgmt-secret.yaml

kubectl apply -f pan-cn-mgmt.yaml

You must run the pan-mgmt-serviceaccount.yaml, only if you had not previously completed the Create Service Account for Cluster Authentication.

Verify that the CN-MGMT pods are up.

It takes about 5-6 minutes.

Use

kubectl get pods -l app=pan-mgmt -n kube-system
Deploy the CN-NGFW pods.
Verify that you have modified the YAML files as detailed in PAN-CN-NGFW-CONFIGMAP and PAN-CN-NGFW.
containers: - name: pan-ngfw-container image: <your-private-registry-image-path>
Use Kubectl apply to run the pan-cn-ngfw-configmap.yaml.
kubectl apply -f pan-cn-ngfw-configmap.yaml
Use Kubectl apply to run the pan-cn-ngfw.yaml.
kubectl apply -f pan-cn-ngfw.yaml
Verify that the CN-NGFW Pods are running.
kubectl get pods -n kube-system -l app=pan-ngfw -o wide
Enable Horizontal Pod Autoscaling on the CN-Series.
Run the following command to verify that you can see CN-MGMT, CN-NGFW and the PAN-CNI on the Kubernetes cluster.
kubectl -n kube-system get pods
Annotate the application yaml or namespace so that the traffic from their new pods is redirected to the firewall.
You need to add the following annotation to redirect traffic to the CN-NGFW for inspection:
annotations:       	   	 paloaltonetworks.com/firewall: pan-fw
For example, for all new pods in the “default” namespace:
kubectl annotate namespace default paloaltonetworks.com/firewall=pan-fw
On some platforms, the application pods can start when the pan-cni is not active in the CNI plugin chain. To avoid such scenarios, you must specify the volumes as shown here in the application pod YAML.
volumes:      - name: pan-cni-ready        hostPath:          path: /var/log/pan-appinfo/pan-cni-ready          type: Directory
Deploy your application in the cluster.